[linux-audio-dev] Call for Works: ICMC 2004
Please excuse cross postings, and freely forward this message to anyone who might be interested. Thank you. Best, Tae Hong Park, ICMC 2004 Publicity Chair Call for Works: ICMC 2004 The University of Miami is pleased to announce the general call for submissions to ICMC 2004, to be held 1-6 November in Miami, Florida USA. These documents, along with PDF submission forms and paper templates are posted on the ICMC 2004 web site at www.icmc2004.org. Best regards, Colby Leider, Chair
Re: [linux-audio-dev] new linux audio hardware company
I think the intention was to say something like "no licensing fee." Like Michael said we'll fix it. Dan On Monday, December 1, 2003, at 03:42 PM, Michael Ost wrote: Thanks for the "debugging". We are looking into it and will correct it. - mo On Mon, 2003-12-01 at 13:02, Tim Orford wrote: Maybe I can answer that, since I work for Muse. I just grep'd the web pages and didn't find 'license free'. Where did you see that? I am a bit mystified by that statement and would like to look into it. its in the mouse-over text for 'museLINUX' in the flash movie. regards -- Tim Orford
Re: [linux-audio-dev] Linux Security Module for realtime audio
> > > 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.
> >
> > Encouraged by your success, I plan to modify this LSM to implement the
> > `kernel/realtime' and `kernel/realtime-group' interfaces we discussed
> > recently. I'll keep you posted on how that progresses.
>
> 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 = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> }
>
> should work fine.
>
> although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz )
> which also allows a process to Override quota limits.
This was needed to make mlockall work (on 2.4.x). CAP_IPC_LOCK was not
enough, I don't know why. We tried removing it and memory locking broke.
Is this on 2.6? Maybe it is different.
Re: the rtc clock, in 2.4 there is a /proc/sys/dev/rtc/max-user-freq
control file that can be used to rise the maximum rtc clock frequency a
normal user can set.
> But because in drivers/char/rtc.c the check is
> if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
>
> it seems like its not possible with the current implementation.
> but we could however provide a jackrtc module which checks for a
> new CAP_RTC_INTS.
-- Fernando
[linux-audio-dev] [ANN] swh plugins release
http://plugin.org.uk/releases/0.4.3/ New plugins: Butterworth filter plugin (Alexander Ehlert) Impulse generator plugin (Andy Wingo) Delay plugin (Andy Wingo) Signal decay plugin (Andy Wingo) DJEQ plugin (me) Reverse Delay plugin (Jesse Chappell) Expander plugin (me, more-or-less untested) Vinyl sound plugin (me) Improvements: Improvements to the IIR filter code (Alexander Ehlert) Gain and delay correction factors for hilbert transformer (Fons Adriaensen) Make biquads internally float/douable at compile time (me) Changes to pitch scale (can't remember why, me) Added latency reporting ports to (most) plugins that need them (me) Updated README and auto* stuff (me) Changes to allow building under Win32 (Audacity Project) Fixed UID clash (me) - Steve
Re: [linux-audio-dev] Linux Security Module for realtime audio
[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 = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
> }
>
> should work fine.
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
patching the kernel. It looks like the new sysfs is intended for this
purpose. I'll investigate.
> although i am not happy with CAP_SYS_RESOURCE ( needed for RTC
> interrupts > 64Hz ) which also allows a process to Override quota
> limits.
Agreed. This is sometimes needed but not always. Maybe it should be
a separate module to use as required.
> But because in drivers/char/rtc.c the check is
> if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
>
> it seems like its not possible with the current implementation.
> but we could however provide a jackrtc module which checks for a
> new CAP_RTC_INTS.
Can you add a new capability without patching the kernel?
--
joq
Re: jack context switches (Was: Re: [linux-audio-dev] another kernel patch?)
>> The actual JACK process cycle works like this: >> jd->A->B->jd > >How? > >How can B start immediately after A without ANY >jackd running in between? > >(I am talking about external clients) yes, its cute eh? to expand slightly on steve's answer: the clients have opened a pair of FIFO's that connect them into the graph. they block on read() of one of them and when they are done with process(), they write() to the other. they don't know who they are waking up (could be jackd, could be another client). of all the ideas in JACK, this is perhaps the "cleverest" :) --p
Re: jack context switches (Was: Re: [linux-audio-dev] another kernel patch?)
On Tue, Dec 02, 2003 at 08:46:39 +0100, Roger Larsson wrote: > > The actual JACK process cycle works like this: > > jd->A->B->jd > > How? > > How can B start immediately after A without ANY > jackd running in between? Through the magic of libjack. The clients are told who to wake up next. - Steve
Re: [linux-audio-dev] Linux Security Module for realtime audio
On Sun, Nov 30, 2003 at 10:10:45PM -0600, Jack O'Quin wrote:
> [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.
>
> Encouraged by your success, I plan to modify this LSM to implement the
> `kernel/realtime' and `kernel/realtime-group' interfaces we discussed
> recently. I'll keep you posted on how that progresses.
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 = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
bprm->cap_permitted = CAP_IPC_LOCK | CAP_SYS_NICE | CAP_SYS_RESORCE
}
should work fine.
although i am not happy with CAP_SYS_RESOURCE ( needed for RTC interrupts > 64Hz )
which also allows a process to Override quota limits.
But because in drivers/char/rtc.c the check is
if ( capable( CAP_SYS_RESOURCE ) ) { allow higher freq }
it seems like its not possible with the current implementation.
but we could however provide a jackrtc module which checks for a
new CAP_RTC_INTS.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
jack context switches (Was: Re: [linux-audio-dev] another kernel patch?)
On Tuesday 02 December 2003 02.50, Jack O'Quin wrote: > Roger Larsson <[EMAIL PROTECTED]> writes: > > But it is still a way to see that no client burns cycles where it should > > not - jackd would not start (or stop). And you _can_ get fewer context > > switches, but only if some client burns extra cycles. > > > > Compare: > > > > With jackd as highest priority: > > Context switches: A->jd [start B] ->A [tail] ->B->jd > > > > With jackd as lowest priority: > > Context switches: A->jd->B->jd > > The actual JACK process cycle works like this: > jd->A->B->jd How? How can B start immediately after A without ANY jackd running in between? (I am talking about external clients) /RogerL -- Roger Larsson Skellefteå Sweden
Re: [linux-audio-dev] Re: mini Review: Re: [Jackit-devel] latest CVS commit
On Tuesday 02 December 2003 05.16, Paul Davis wrote:
> >On Monday 01 December 2003 20.48, Paul Davis wrote:
> >> i'd appreciate test reports ASAP, so that out trusty release
> >> technician (the very wonderful taybin rutkin) can get a new release
> >> out in the near future.
> >
> >alsa_driver.c
> >
> > driver->period_usecs =3D
> > (jack_time_t) floor float) driver->frames_per_cycle) /
> > driver->frame_rate) * 100.0f);
> >
> >jackd/engine.c
> > poll_timeout =3D (engine->control->real_time =3D=3D 0 ?
> > engine->client_timeout_msecs :
> > engine->driver->period_usecs/1000);
> >
> > - - -
> >
> > if (poll (pfd, 1, poll_timeout) < 0) {
> >
> >Isn't this dangerous?
> >* What happens if period_usecs < 1000?
> > Well poll_timeout gets 0 since period_usecs is an uint64_t
> > A poll with time out of zero will return immediately.
> > OK?
>
> well, there is no alternative really. the kernel has no time
> resolution less than 1msec even on modern kernels with HZ=1000. so
> setting it lower could be rather risky, given the use of busywaits for
> some other SCHED_FIFO delays (see the code for usleep).
>
> but yes, you are right, it is dangerous. we should probably sleep for
> max (1msec, period_msecs). agree?
Either that or (period_msecs + 1)
You should get a solid lockup if your period_msecs is lower than 1000 us ==
1 ms when running SCHED_FIFO... (unless you run clients at the same
priority and the kernel yields at poll - I don't think it does)
/RogerL
--
Roger Larsson
Skellefteå
Sweden
