of incompatible C++ compiler implementations.
Regards,
--
Jack O'Quin
Austin, Texas, USA
to share an address space. Giving each
application in its own process allows it to use any user interface
tools it wants, independent of other applications' choices.
Check the list archives for a full discussion of this and other
issues. It was an interesting discussion.
Regards,
--
Jack
be
useful, and such a script can easily read config files with no extra
library dependencies in JACK.
--
Jack O'Quin
Austin, Texas, USA
BTW, like everyone else, I like Takashi and Paul's idea of running the
JACK engine in-process if libjack finds that no daemon is running.
on the information provided.
I sincerely wish you good luck with RTMix...
--
Jack O'Quin
Austin, Texas, USA
.
If you're using JACK anyway, this is an easy solution.
There are lots of other facilities available. I'm sure others will
explain their advantages and disadvantages. :-)
--
Jack O'Quin
Austin, Texas, USA
carrying all the
people going to *that* standards group meeting! ;-)
Regards,
--
Jack O'Quin
Austin, Texas, USA
.
Once I realized what had happened, I subscribed to LAU as well.
Problem solved. :-)
So, I would vote++ for the suggestion to moderate non-member postings.
--
Jack O'Quin
Austin, Texas, USA
version included in the JACK example-clients
directory. These are excellent for some problems, but certainly
not for everything.
Advice or comments?
--
Jack O'Quin
Austin, Texas, USA
as you use
GCC or a compatible compiler. They are mad for user space and
survive even preemption quite well.
So, how are you actually using them? Are any of these services
exported, or do you copy header files out of the linuxthreads source
tree?
Regards,
--
Jack O'Quin
Austin, Texas, USA
to
collect all these header files and wrap them with appropriate
#ifdef's, right? Or else, I could put them in subdirectories and
select the right one at ./configure time.
--
Jack O'Quin
Austin, Texas, USA
Paul Davis [EMAIL PROTECTED] writes:
we're all rich! yippee! who's going to collect?
As benevolent dictator, it should certainly be you, Paul. :-/
--
Jack O'Quin
Austin, Texas, USA
(InterlockedCompareExchange, dest, exch, cmp);
}
But, I can't figure out where the ice_wrapper stuff is defined. I
suspect it may be the interesting part, some kind of machine-dependent
layer.
Regards,
--
Jack O'Quin
Austin, Texas, USA
. :-)
Don't sweat the responsibility Steve, you can always solicit input.
--
Jack O'Quin
Austin, Texas, USA
the best models to base it on. I'm going to try
using the SourceForge compiler farm as a test lab.
Thanks again for the pointer.
Regards,
--
Jack O'Quin
Austin, Texas, USA
not contribute to http://www.djcj.org/LAU/guide?
--
Jack O'Quin
Austin, Texas, USA
this. :-)
Regards,
--
Jack O'Quin
Austin, Texas, USA
addresses. I got that straightened out, but have
since become sensitive to this kind of blanket treatment.
Punish me (if you must) for what I do, not for my connection protocol.
Regards,
--
Jack O'Quin
Austin, Texas, USA
.
Regards,
--
Jack O'Quin
Austin, Texas, USA
.
If this is not clear, then we need to beef up the JACK documentation.
I guess that goes without saying, anyway. ;-)
Regards,
--
Jack O'Quin
Austin, Texas, USA
Robert Jonsson [EMAIL PROTECTED] writes:
That be very nice. Transport is something that I would personally
find useful (though I haven't checked what is available).
Nothing as readable as James' excellent tutorial. But there is a
section in the Fine Manual...
a segfault in
lookahead_limiter_1435.xml, line 110.
So, what version of swh-plugins works for jackEQ?
--
Jack O'Quin
Austin, Texas
I am cross-posting this to LAD, hoping to get some useful feedback.
Paul Davis [EMAIL PROTECTED] writes:
about that patch ... torben hohn wrote, some time ago on LAD (see his
comment at the end). does anyone have time to check on this?
Have a look at linux security modules. In the 2.5
Iain Duncan [EMAIL PROTECTED] writes:
Thanks for the all the interesting responses. I did some thinking and a few
experiments, and I think the best way to do it would be to use an amplitude
modulated sine ( actually triangle ) wave at one have the nyquist, precisely
1/4 of sample rate.
Why
Jussi Laako [EMAIL PROTECTED] writes:
I've written preliminary OSS driver for JACK. Patch for jack 0.80
attached.
With current CVS you can just run `jackd -d portaudio'.
--
Jack O'Quin
Austin, Texas
as well as
realtime privileges.
--
Jack O'Quin
Austin, Texas
).
Would you mind terribly redirecting some of this fine work in the
direction of testing and fixing problems with the PortAudio driver,
instead?
Regards,
--
Jack O'Quin
Austin, Texas
Paul Davis [EMAIL PROTECTED] writes:
But, I would much prefer to do that than to take on the extra
maintenance load for yet another driver (we already have three).
i welcome as many drivers as people can provide, on the understanding
that they will not necessarily be maintained by anyone
Jussi Laako [EMAIL PROTECTED] writes:
Does PortAudio support 24/32 bit formats and more than 2 channels or
samplerates over 48 kHz?
All my experience is with my home system, which runs ALSA drivers
using the OSS emulation interfaces. I suspect things would probably
work differently using one
Jack O'Quin writes:
One of the things I like about the `audio' group approach is that
it is easy to administer and simple to verify who has access to
those privileges.
martin rumori [EMAIL PROTECTED] writes:
i think, that's a clean solution. to be able to distinguish between
realtime
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
As far as I understand these are the current options:
a) capabilities
b) simple sysctl patch to the kernel (like the one that Kjetil posted)
c) security module, with possible additional control through sysctl
b is better than a (more
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional
martin rumori [EMAIL PROTECTED] writes:
Also, 0 is a valid group ID, `root', which might be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
Yes, probably nogroup is the best option. I
Melanie [EMAIL PROTECTED] writes:
Wouldn't it, just maybe, be acceptable to the kernel people if
capabilities could be turned on by some parameter on the kernel
command line (e.g. capabilities=on)?
We could ask. But, I suspect they will feel that they have adequately
solved this problem in
Melanie [EMAIL PROTECTED] writes:
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with
Roger Larsson [EMAIL PROTECTED] writes:
Problem is - why doesn't most distributions even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional)
That seems logical, but
Roger Larsson [EMAIL PROTECTED] writes:
But on those audio workstations you have NO problem to make
wrappers suid root.
* The audio workstation case can always be handled.
* The problematic case is common desktop where users get a much worse
experience than they should - and it might
Kjetil Svalastog Matheussen [EMAIL PROTECTED] writes:
I couldn't wait til you found it, so I wrote one from scratch instead. :)
The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is
very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1.
Kjetil Svalastog Matheussen [EMAIL PROTECTED] writes:
I did this as a baseline before adding the `realtimegroup' logic we
discussed last week. I think I'll attempt that next, after fixing
the SCHED_RR omission.
I thought about hacking together those additions after it was posted,
but
Kjetil Svalastog Matheussen [EMAIL PROTECTED] writes:
I still like a module idea though. I dont see the point of
patching the kernel with the security module interface, except for the
security. What I would like, though, is:
This idea makes sense. If there is a requirement for clean,
Paul Davis [EMAIL PROTECTED] writes:
a new system call. call it switch_to(). takes a PID (actually, it
needs some kind of TID), and does something very similar to
sched_yield() except instead of giving up the processor to whatever
the scheduler thinks is right, it yields to the specific
Paul Davis [EMAIL PROTECTED] writes:
the problem is not (just?) the time that the scheduler takes. its that
its decision making process is opaque. when jackd runs, it knows for
certain which pid/tid to run next. we don't want to cede control of
that back to the kernel scheduler.
No
Roger Larsson [EMAIL PROTECTED] writes:
If next client is a RT process (SCHED_FIFO/RR) then it WILL be selected
unless there is another RT process with higher priority, and lower than jackd
otherwice it would have been running in the first place.
I wish this were the true. But, I strongly
Roger Larsson [EMAIL PROTECTED] writes:
That's right. But, Paul and I have been working closely with this and
don't have much faith in the correctness of the 2.4 scheduler.
Have you told kernel developers about this?
This can be rather critical in embedded systems.
No. It's rather
[EMAIL PROTECTED] wrote:
attached is what i have done today works, but needs to
be checked by someone who can judge about the sideeffects.
i am not so sure about them.
I can't comment on the overall security of your module, Torben.
But, I did finally find time to try it out, and it
Takashi Iwai [EMAIL PROTECTED] writes:
Jack O'Quin wrote:
But, I have no reason to believe that it works correctly, and I
suspect that it probably does not.
as Roger pointed, the O(1) scheduler does quite simple tasks for RT
processes. it *should* work. if it deson't work, it's a bug
Paul Davis [EMAIL PROTECTED] writes:
but yes, you are right, it is dangerous. we should probably sleep for
max (1msec, period_msecs). agree?
I agree.
Since the exact duration of the timeout probably doesn't matter that
much, I am experiementing with just adding one to period_msecs.
--
[EMAIL PROTECTED] writes:
the most simple way would be parameters given to the module for the
realtime group and user. There are nice macros for module parameters.
i believe that adding to the currently overridden function
if( bprm-e_gid == realtime_gid ) {
bprm-cap_effective =
[EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack O'Quin wrote:
That's pretty much what I have in mind. I'm still trying to figure
out how to pass the group id as a parameter somewhere. I wanted to
use /proc/sys/kernel/realtime-group, but that seems to require
Luke Yelavich [EMAIL PROTECTED] writes:
I am currently preparing an updated kernel, and am wondering whether
any of the proposed patches for a 2.4 kernel are stable enough to be
usable. If so, where can I obtain the patches?
The most stable and best-tested is the two-line capabilities patch.
Joern Nettingsmeier [EMAIL PROTECTED] writes:
reading lwn.net this morning i found that the linux journal has a new
linux audio column in their online edition, written by dave phillips.
the current issue is at
http://www.linuxjournal.com//article.php?sid=7283 .
Many thanks to Dave for this
I've been experimenting with Torben's LSM for the 2.6 kernel, and the
realtime group permissions mechanism we discussed.
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
(process:11284): Gtk-WARNING **: This process is currently running
On Sat, Dec 06, 2003 at 06:35:45PM -0600, Jack O'Quin wrote:
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
[EMAIL PROTECTED] writes:
hmm... perhaps we trick the binary by setting the gid back
to the e_gid after enabling capabilities
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
The sgid approach is in addition to having a realtime group or
instead? I have the feeling I have missed something in the thread.
The setgid approach *is* a match on the realtime group. The question
is which of several group IDs to you
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
Thanks for the clarification, I was getting confused... so the GTK
problem only happens if you try to tag executables only for realtime
access.
Right. GTK complains if its executable uses either setuid or setgid.
This is regrettable,
Tim Hockin [EMAIL PROTECTED] writes:
I apologizer if this has been discussed, but I haven't read the whole
thread. Has the idea of a simple sched_rr helper been discussed?
Roger Larsson has an rt_monitor program that can do most of what you
suggest. It also limits the fraction of the CPU
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
thats why i dont consider it necessary. what do you need the proc entry
for fernando ?
Just asking, I guess it is not really needed, just unloading and loading
should be enough. It would be nice to have some sort of confirmation
from
Here is the realtime LSM version 0.0.2, for use with 2.6 kernels.
-- New features
- mlock parameter enables memory locking privileges
- allcaps parameter enables all capabilities, including CAP_SETPCAP
- restores cap-bound on exit
-- Makefile improvements
- use
[EMAIL PROTECTED] writes:
setting up a proc readable file is not so hard.
Tim Hockin [EMAIL PROTECTED] writes:
making a proc file is trivial, really. I have lots of example code
for simple proc file interfaces (read and write). Need it?
I've been looking at that, and plan to do it next. A
[EMAIL PROTECTED] writes:
i talked to tim janik on #lad yesterday and he said, that we should mail
gtk-devel-list and CC: owen taylor with a description of the problem,
and with a statement that we have read setuid.html.
what we need is, that the test must be for [ug]id == 0 and not
is evolving in directions that are outside the scope
of GTK and cannot adequately be enforced by any user-level library.
Despite good intentions, incomplete security checking tends only to
make matters worse.
Regards,
--
Jack O'Quin
Austin, Texas
[1] mailto:[EMAIL PROTECTED]
[2] http
Jens M Andreasen [EMAIL PROTECTED] writes:
I am in a very bad mood today, so I thought that it would be good for
you if I did some critisiscm of this draft.
Good. Every project needs a curmudgeon. ;-)
On Fri, 2003-12-12 at 05:05, Jack O'Quin wrote:
Historically, many Linux audio
Paul Davis [EMAIL PROTECTED] writes:
i was trying to install swh-plugins and freqtweak on my new laptop and
ran into some problems with the planet's rpms. they seem to depend on
a feature libfftw3f.so.3 that isn't being supplied by any other
package. i have fftw3 installed, and it gave me the
Florian Schmidt [EMAIL PROTECTED] writes:
i wonder about how ready linux 2.6.0 is for audio stuff? Is vanilla
2.6.0 with preemtion enabled comparable to 2.4.22 with preemption +
andrew's LowLatency patches [which i use right now]?
On my system, the vanilla 2.6 with preemption is usable for
The first stable release (0.8.0) of JAMin - the JACK Audio Mastering
interface is now available for download.
JAMin is a GPL licenced, state-of-the-art realtime mastering processor
designed to bring out the detail in recorded music and provide the
final layer of polish. Every effort has been
Juhana Sadeharju [EMAIL PROTECTED] writes:
What is /dev/shm? How it is used? df shows:
none 62812 0 62812 0% /dev/shm
On many systems it is a mount point for a tmpfs filesystem. This is
required by some POSIX shm implementations (shmopen(), etc.). I think
Dave Robillard [EMAIL PROTECTED] writes:
One suggestion: I think it'd be useful to list what interfaces the app
supports, I know at least for me if it doesn't use jack it's basically
useless (and I'd rather find this out before downloading the whole
thing!)
The audio distributions (such as
Vincent Touquet [EMAIL PROTECTED] writes:
Would you consider implementing a work around (aka non portable kludgery)
a waste of time ?
In the 2.4 kernel this test in mm/mlock.c limits page locking to half
of physical memory...
/* we may lock at most half of physical memory... */
Arve Knudsen [EMAIL PROTECTED] writes:
The thing is I don't have complete control over the audio thread, a
user defined callback is involved. In working on the ALSA
implementation of the PortAudio library there has been a request for
realtime scheduling of the audio thread, similar to the
Arve Knudsen [EMAIL PROTECTED] writes:
True .. That was one approach I considered originally while sketching
up solutions, I guess it slipped my mind in the meantime :| I was
thinking it could possibly be an expensive operation though as NPTL
sources seem to indicate, maybe best avoided if
On 31 Mar 2004 11:39:36 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
It doesn't look all that expensive. The magic is done by a platform-
dependent compare-and-swap operation. On some SMP machines that can
be slow, but generally only in high-contention situations (AFAIK).
Arve Knudsen
Arve Knudsen [EMAIL PROTECTED] writes:
What about pthread_kill with a user defined signal (SIGRTMIN = sig =
SIGRTMAX), where the handler will call pthread_exit? Then the
registered cleanup functions should be invoked as usual.
That might be better. I haven't tried doing it that way, myself.
Richard Bown [EMAIL PROTECTED] writes:
Are you using the stock 2.4.21 kernel? Any idea how to enable
capabilities on it? I've been playing around with SuSE 9.0 over the
last couple of days and with an SBLive am only get reasonably
xrun-free performance with jackd at 2048, 2 periods. I'd
that enables realtime
capabilities for any 2.6 kernel without needing to directly patch the
kernel. It was written by Torben Hohn and Jack O'Quin, who make no
warranty concerning the safety, security or even stability of your
system when using it. It is provided under the provisions of the GPL
Takashi Iwai [EMAIL PROTECTED] writes:
IMO, the only concern about saying it's a part of hardware is that
you can redistribute the firmware while you cannot do the hardware.
this is the basic difference between hardware and software.
Depending on how you define the term, I suppose one can
Maarten de Boer [EMAIL PROTECTED] writes:
a collegue pointed me to this post about a high resolution time
patch for the 2.6.5 kernel. i'm not 100% if it has been mentioned
here before, nor of how much interest it is, but just in case.
http://lwn.net/Articles/81400/
Thanks for the pointer.
Robert Jonsson [EMAIL PROTECTED] writes:
As a service to all readers, here's an excerpt of the Changelog concerning
latency: ;)
[...]
So... humbly asking, is it time yet to make the switch? :-)
Maybe. If you do and you're using the realtime LSM, you're going to
need the latest (beta)
Paul Davis [EMAIL PROTECTED] writes:
personally, i think its worth going through this pain. we will end up
with a system in which new LADSPA extensions do not require changes to
the API, which is a great thing. but it will be painful to get there,
and i want to check that people don't mind
Steve Harris [EMAIL PROTECTED] writes:
On Fri, May 14, 2004 at 04:50:31 +0200, Alfons Adriaensen wrote:
I don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
Human readable and line by line parsable are pretty much
Fons Adriaensen [EMAIL PROTECTED] writes:
On Fri, May 14, 2004 at 11:31:01AM -0500, Jack O'Quin wrote:
I'm having trouble figuring out Fons' original point here, though I'm
sure he has one. Simple and human readable are worthwhile goals, but
hard to reconcile.
Strange.. I'd think
jaromil [EMAIL PROTECTED] writes:
would have been a good choice since the beginning, to have it as a lib?
Maybe so. But, it's important to keep this in perspective.
LADSPA has been a great success, and simplicity was one of the main
reasons. Now that the concept is proven, people are willing
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
I tend to look at it (very conveniently, of course) as neither. I view
it as part of the hardware device we're dealing with. Without it the
device does not work. It is distributed as a separate file (inside the
driver disk that actually
.
This LSM was written by Torben Hohn and Jack O'Quin, who make no
warranty concerning the safety, security or even stability of your
system when using it. But, if you do have problems, we would like to
know about them via the SourceForge bug tracking system.
--
joq
Tim Goetze [EMAIL PROTECTED] writes:
sounds fair enough, but still requires you to install X and the
toolkit of the plugin's choice.
I must have missed something. I thought you could send the
configuration parameters from a command line.
--
joq
Frank NEUMANN [EMAIL PROTECTED] writes:
http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2004/photos/
Thanks for the photos, Frank.
Can you (or anyone) name all the people in this group picture?
Dave Robillard [EMAIL PROTECTED] writes:
So, ++xml, because reinventing the wheel is stupid. While I understand
the kneejerk anti-xml reaction (damn buzzwords) it just seems like the
right tool for the job...
I've been reading up on Steve's N-triples suggestion...
NTriples is defined in
Steve Harris [EMAIL PROTECTED] writes:
On Thu, May 27, 2004 at 12:41:36 +0200, Tim Goetze wrote:
other than that, i'm eager to know how plugin ports are to be
referenced in the metadata file. by ID or numerical index? if by ID,
is it the full path to the port: /SupaPlug/LFO 1/Frequency, or
Ivica Ico Bukvic [EMAIL PROTECTED] writes:
Hasn't there been some success stories in the past regarding this? I
might be obviously very wrong about this but I thought that if one
designed a meta-device in the asoundrc making two soundcards one
multichannel soundcard and then invoking JACK on
Ivica Ico Bukvic [EMAIL PROTECTED] writes:
Forgot to add that my assumption is (in addition to my previous
statement) if JACK was then running using reasonably small buffers
the drift would be then minimized if not alleviated since JACK is
one that is dispatching the buffers at appropriate
Tim Hockin [EMAIL PROTECTED] writes:
On Fri, Jun 11, 2004 at 01:21:51PM -0400, Paul Davis wrote:
more seriously, its necessary to be able to escape from
programming. if not the bedroom, then where?
but then how do you wake up when you r build is done?
make echo ^G^G
That only wakes
Pete Bessman [EMAIL PROTECTED] writes:
One more point in favor of GThread I just figured out is config
testing for it. All you have to do is at a pkg-config check for
gthread-2.0 and your set. Having glanced through other programs,
checking for pthreads seems a bit more involved than I care
Michael Ost [EMAIL PROTECTED] writes:
Does a signal handler (like segfault, or divide by zero) run at the
priority of the thread that it gets generated for?
Those signals in particular are defined by POSIX to be synchronous,
meaning they should be delivered to the thread creating them. Thus
Martijn Sipkema [EMAIL PROTECTED] writes:
(the lock-free ringbuffer is a special case since the only
synchronizing that is done, i.e. read/write access to an int, is
done by the processor. I'm not convinced that this will work on all
architectures)
I can't think of any architecture on which
The second stable release (0.9.0) of JAMin - the JACK Audio Mastering
interface is now available for download.
JAMin is a GPL-licensed, realtime mastering processor designed to
bring out the detail in recorded music and provide a final layer of
polish. Every effort has been made to ensure a
Paul Winkler [EMAIL PROTECTED] writes:
Another interesting comparison is modular digital multitracks
such as ADAT and DA-88. Anybody know how sync works on those
beasties?
I think ADAT sends a wordclock-like pulse over the optical link. One
machine is master. All the others slave their
Steve Harris [EMAIL PROTECTED] writes:
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
If I understood it correctly, yes it does, but their concept of a
network is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses
I wholly agree with Simon's point that most lock-free structures are
good enough for practical purposes.
But, like him, I enjoy a good theoretical discussion, sometimes.
Simon Jenkins [EMAIL PROTECTED] writes:
Bah! Woke up with a hangover and now I'm eating words for breakfast.
After one of
Lee Revell [EMAIL PROTECTED] writes:
Anyway if the author does not object, I would be willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
It's fine with me. I agree that it makes sense, but have not
Steve Harris [EMAIL PROTECTED] writes:
I really need to set up some kind of bugtracking thing for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind
Lee Revell [EMAIL PROTECTED] writes:
Are there any known issues with the code that the kernel guys might
bring up? Seems like it has been stable for a while. The only thing I
notices was that the indentation doesn't follow the recommended kernel
style.
It meets the recommendations I know
Lee Revell [EMAIL PROTECTED] writes:
Isn't a DoS attack also the worst case scenario with allcaps? Or am I
missing something?
No, it's not. There is a scenario where an intruder uses SETPCAP to
deny root programs access to resources they need (like system logs).
I don't know all the
1 - 100 of 157 matches
Mail list logo
