Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[martin rumori]

On Mon, Nov 17, 2003 at 09:59:11PM -0600, Jack O'Quin wrote:
> martin rumori <[EMAIL PROTECTED]> writes:
> > senseless) as default.  granting realtime privileges to everybody is
> > exactly what we don't want...  and it's likely to do that by accident

> I agree that 0 should be the default.  It exists on every system and
> is rather restrictive, so people won't accidentally grant more access
> 
> To summarize, my proposal is:
> 
snip

> Only root can write these variables.  If possible, let's agree on a
> standard gid to use for group `realtime', there isn't one now.

looks like a clean solution.

cheers, martin

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Jack O'Quin]

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 AFAICT the actual reason is because of a
security hole introduced by CAP_SETPCAP (which was not part of the
original POSIX draft spec).  Before this screwup was detected, kernels
shipped with capabilities enabled.

If an attacker manages to subvert one of the system daemons with a
buffer overflow (sendmail is a frequent target), it can use
CAP_SETPCAP to deny capabilities to other system services that need
them to perform their jobs, including monitoring system security.

> So with any scheme that opens up these holes you have to deliver a way
> to protect from the downsides.

Clearly this is desirable.  But, for many audio workstations it is
*not* mandatory.

> My monitor protects from CPU overuse, but what about memory?
> How to protect from an application that mlockall(MCL_FUTURE) and
> has a memory leak?

If you fail to solve this problem, then we end up back where we are
right now: patching kernels or running untrusted audio applications as
root.  This solution is much worse than the problem you were trying to
solve.

> One important thing to remember - if you like to get broad acceptance
> you have to suggest a solution that solves these problems. I would say
> that the rt_monitor or some other means to do the same thing is
> mandatory to get that kind of acceptance.

But, only if it works.  It would really be great if you *could* come
up with a solution.

> > The big difference between realtime and most other kinds of
> > performance work is that it focuses on tuning the "worst case", not
> > the average.  Paging works fine on average, but in the worst case your
> > recording session gets blown.
> 
> SCHED_FIFO does not make ANY guarantees on "worst case"!

I didn't mention "guarantees", I spoke of "focusing on tuning".  Big
difference.

SCHED_FIFO is a blunt instrument.  By itself, not adequate for much of
anything.  Used in conjunction with carefully tuned hardware and
software, a low-latency kernel, and a known set of well-written audio
applications, rather decent realtime performance can be achieved with
only commodity hardware and free software.  That's not bad.

> > Otherwise, a good solution.  Perhaps adequate for some applications.
> 
> But at the same time SCHED_FIFO is adequate for most applications.
> 
> See my point? :-)

No, I don't.
-- 
  joq

Re: [linux-audio-dev] plugin GUIs .. Mediastation, LADSPA ?

[Benno Senoner]

Disclaimer: I have not read the entire GUI thread so please don't flame 
me (but correct me)
if I say nonsense.

Having written a few engines (midi player, audio player) and the 
corresponding GUIs of
the upcoming Lionstracs Mediastation keyboard, we have faced the same 
problem old problem:
we wanted the GUIs decoupled from the engines, perhaps allowing 
controlling the engine
by more than one GUI at the same time where all GUIs automagically 
update themselves
when the engine (or other GUIs) change its parameters.

I decided to adopt the simplest possible protocol perhaps it is a bit 
inefficient compared
to the most elegant solution but I think the simplicity of my model 
cannot be beaten that easily.
I'd like you folks to read the brief explanation of my protocol and make 
comments about it,
eg. if an even more simple solution exists, or if it has serious flaws 
(I don't think so :-) )

Let's explain a simple scenario:
I midi player which consists of a GUI-less engine and a GUI.
It's basically a client/server system: GUIs are clients, engines are 
servers.
The midi player accepts commands like
load filename.mid
start, stop, seek, get_engine_status

the method I use to communicate between the GUIs is SYSV message queues
because they can be multiclient but the API is abstracted so the 
underlying transport
model can be chosen arbitrarily.

the server does:

// opens a message port in server mode (creates the port)
// key is needed to identify the port by clients that
// will connect to
int mcmd_open_server_port(int key, mcmd_info_t *mcmd_info);

key is a machine wide unique identifier.
in my implementation it's just the SYSV IPC message queue key,
but this is not mandatory, the API can easily be adapted to use
strings (eg for TCP/IP support which I will add soon).
now within the main loop the server does:

// receives a message. If no message is pending in the queue
// wait until message was received
int mcmd_receive(mcmd_info_t *mcmd_info, void *buffer, int buflen)
and then based on the type of message received it performs some action
and sends back a response to the client which can be a simple ACK or
a message containing some payload
it does so using this function:

int mcmd_send(mcmd_info_t *mcmd_info, void *buffer, int buflen, int 
destination)

The destination is an unique identifier of the client that sent the message
So basically each server and client do have unique identifiers
which in my implementation are mapped to SYSV IPC struct msgbuf.mtype 
values
(but this is only an implementation detail, as said the communication 
layer can be
any form of IPC)

I have the mcmd_receive_nowait() call too which can be directly placed 
within a high
priority thread that does other stuff too (eg a midi/audio playing thread).
SYSV msg queues seems quite fast a couple of usecs (or dozen of usecs) 
per call so
perhaps one could probably even put msgrcv() calls into an audio 
processing loop that does
process audio fragments of 1-2msec. Not sure if there is some locking 
that might cause stalls.
If you are paranoid you could let an audio player accept external 
commands via lower priority
thread and then pass these commands to audio thread via lock-free FIFO, 
or even better
use lock-free fifos as the transport method of the mcmd_ API.

So far so good, let's continue with the MIDI player scenario:

The GUI user wants to load a midi file.
the command sent to the server is load_file file.mid
the server executes it (loads the file.mid) and then responds
with an ACK. (with a status code so that the GUI knows if loading succeded).
Same for start,stop, change volume of midi channel, etc commands.
Now let's see how the GUI updates itself: we want the time display to 
advance,
and midi volume sliders update automagically.

Basically the GUI has a timer callback that is called 10-20 times/sec.
It sends a GET_ENGINE_STATUS message to the server
and the server responds with a ENGINE_STATUS message.
this message (you can define your own arbitrary message structs because the
protocol does not know anything about the payload of messages.
This engine status message should contain the values that should 
exported to the GUI
in the midi player's case the current position (midi ticks), current 
values of midi volumes,
muted channels and so on.
If the payload gets too big then export flags that signal that some 
parameters in the engine
changes and then let the GUI request an additional info packet that 
contains the values
you need.
The guideline should be to minimize the number of messages exchanged so 
in my
specific case I have chosen to put all parameters needed in single 
packet (100-200bytes).

Of course the GUI should do something like this to avoid unnecessary 
repainting
of elements (which could lead to a slow, flickering GUI)

if(curr_volume != old_volume) update_volume_slider(curr_volume);

In my example midi player you see the volume sliders move when the there 
are volume
changes in the player engine because the GUI

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Roger Larsson]

On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote:
> >ping is answered = IRQs live.
> >Could you please try this.
> >Start rt_monitor in a text console CTRL-ALT-F1
> >
> >Start your client, return to console - what does rt_monitor print?
> >
> >(It could be the memory leak and mlockall(FUTURE) problem,
> >As I do not check that yet.
> >Another alternative is a fast forking client - they are hard to stop)
>
> OK, I tested it. There is no output at all from rt_monitor.
> I used the following:
> - starting rt_monitor in a console as root
> - ssh login from remote machine
> - starting jack
> - starting a jack client

What client? Any client?

>
> after a few seconds the machine was froozen and no output
> from rt_monitor.

Hmm...

> I assume its a hardware bug. On my Inspiron 8500 with nearly
> the same linux-2.4.19.SuSE kernel (plus patch for speed-step)
> I dont have any freezes at all.

But you do have it recompiled for the right CPU architecture
and not only moved?

BTW: There is a prefech bug on AMD processors - try to run it recompiled
with less optimization, newer kernels have workarounds.

Another thing to try is to run memtest86 (SuSE has it in Lilo menu)
let it run for a while (full night)

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Jack O'Quin]

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 complete confidence that even if you do not use the cmdline arg
> > that the presence of capabilities support does not pose a security issue.
> 
> Well, capabilities are _always_ compiled into the kernel. The only
> thing changed to enable them are two static data values, specifically
> the ones used to start init with. This happens in one place and one
> place only. Instead of #defines, these could be globals. Of course
> they would need to be set before init is run, so a kernel command line
> parameter is the only place it can be done easily.

This is true.  It would be easy to change and only affects two values.

But, if you consider the situation of servers running in a colocate
environment, many sysadmins would want to prevent even people with
physical access to the machine from being able to change their
security model so drastically.
-- 
  joq

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Melanie]

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 complete confidence that even if you do not use the cmdline arg
that the presence of capabilities support does not pose a security issue.
Well, capabilities are _always_ compiled into the kernel. The only thing 
changed to enable them are two static data values, specifically the ones 
used to start init with. This happens in one place and one place only. 
Instead of #defines, these could be globals. Of course they would need to 
be set before init is run, so a kernel command line parameter is the only 
place it can be done easily.
Nothing changes thoughout the kernel but these two data values...

Melanie

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Paul Davis]

>On 2003.11.18 21:02 Paul Davis wrote:
>> i'm with fernando on this. we are not looking for broad acceptance,
>> though it would be nice. it would be great if this showed us a
>> config-time option for the kernel, but i think its unlikely. more
>> likely than caps being turned on by default, though.
>
>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)?
>This would make capabilities disabled by default, but gives a way to enable 
>them that does not require a kernel patch and rebuild...

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 complete confidence that even if you do not use the cmdline arg
that the presence of capabilities support does not pose a security issue.

by contrast, kjetil's patch has very deterministic and very local
effects, and when its off, we know its off.

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Jack O'Quin]

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 2.6 by providing the pluggable security module
infrastructure.  This was doubtless motivated by a strong desire to
*avoid* such discussions with an endless procession of people like us
with "special security needs".  

>From that perspective, security modules look like an excellent
solution.

> This would make capabilities disabled by default, but gives a way to
> enable them that does not require a kernel patch and rebuild...

That would be nice, but I don't expect to see it backported to 2.4.
-- 
  joq

Re: [linux-audio-dev] oss driver for jack 0.90 rev3

[Paul Davis]

>On Tue, 2003-11-18 at 23:59, Paul Davis wrote:
>
>> > - Conditionally compiled two thread implementation for NPTL (possibly
>> >   also works with LinuxThreads, untested)
>> 
>> would you mind explaining why you are using 2 threads? it seems
>> pointless, but perhaps i'm missing something...
>
>One is for input and other one is for output. It is especially useful
>when input and output goes through different device/driver/hardware and
>also for SMP. Just allows simultaneous system calls.

if you used poll(2) or select(2), you could do simultaneous waits on
each direction, regardless of whether they use different devices or
not. you'd then reduce the context switches and the overhead of
synchronize(). you could also use the standard no-thread support
infrastructure that JACK now contains, consolidating our ability to
move all JACK drivers forward together. 

i also note that you're also not using mmap, resulting in extra
copying of significant quantities of data on every cycle for
multichannel cards. the cpu cycles for this can be significant when
you get down to very low latency on hammerfall cards, for example. 

i'm not trying to argue against your design - in some ways, its quite
clever. its just that it goes in a different direction than the ALSA
driver does; not entirely suprising given the differences between OSS
and ALSA.

i didn't really sense an answer to my question about your willingness
to maintain your OSS driver in the face of any future changes in
JACK. if i can get a clear answer on this, i'll make a decision about
adding it to CVS.

--p

[linux-audio-dev] ecasound 2.3.1 released

[Kai Vehmanen]

1. A short summary of changes

Ecasound's emacs mode, ecasound.el, has been updated to 
version 0.8.3. Due to severe bugs found in the native Python 
ECI implementation, the C implementation has been again set as 
the default. Minor interoperability problems with older JACK
releases and Ecasound have been fixed. A bug that caused builds
against an external libreadline to fail, has been fixed.
Also recording problems with the WinTv 401Dbx and other 
bt878-based devices have been fixed. This release is compatible
with the upcoming alsa-lib-1.0 releases.

---
2. What is Ecasound?

Ecasound is a software package designed for multitrack audio
processing. It can be used for simple tasks like audio playback, 
recording and format conversions, as well as for multitrack effect 
processing, mixing, recording and signal recycling. Ecasound supports 
a wide range of audio inputs, outputs and effect algorithms. 
Effects and audio objects can be combined in various ways, and their
parameters can be controlled by operator objects like oscillators 
and MIDI-CCs. A versatile console mode user-interface is included 
in the package.

Ecasound is licensed under the GPL. The Ecasound Control Interface 
(ECI) is licensed under the LGPL.

---
3. Changes since last release

Full list of changes is available at 
.

---
4. Interface and configuration file changes

None.

---
5. Contributors

Patches - Accepted code, documentation and build system changes

Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes)
Junichi Uekawa (ecasound makefile bug, doc generation 
using Hevea)
Kai Vehmanen (various)

Bug Hunting - Reports that led to bugfixes (items closed)

Hirendra Hindocha (2) --  recording problems with WinTv 401dbx, 
  ecacontrol.py bugs
Stefan Bundt (1) -- ecacontrol.py breaks under heavy load
Dave Phillips (1) -- errors in EIAM help
Junichi Uekawa (1) -- compability bug with older JACK versions

---
6. Links and files
   
Web sites:
http://www.eca.cx
http://www.eca.cx/ecasound

Source packages:
http://ecasound.seul.org/download
http://ecasound.seul.org/download/ecasound-2.3.1.tar.gz

Distributions with maintained Ecasound support:
Agnula - http://www.agnula.org
Debian - http://www.debian.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
SuSE Linux -  http://www.suse.de/en

Contrib Packages and Add-On Distributions:
AudioSlack for Slackware - http://www.audioslack.com
PlanetCCRMA for RedHat/Fedora 
- http://www-ccrma.stanford.edu/planetccrma/software
Thac's RPMs for Mandrake - http://rpm.nyvalls.se
Apps.kde.com packages for Mandrake/Redhat/SuSE
- http://apps.kde.com/rf/2/info/id/2146

Note! Distributors do not necessarily provide packages for 
  the very latest Ecasound version.

--
 http://www.eca.cx
 Audio software for Linux!

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Melanie]

On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
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)?
This would make capabilities disabled by default, but gives a way to enable 
them that does not require a kernel patch and rebuild...

Melanie

Re: [linux-audio-dev] oss driver for jack 0.90 rev3

[Jussi Laako]

On Tue, 2003-11-18 at 23:59, Paul Davis wrote:

> > - Conditionally compiled two thread implementation for NPTL (possibly
> >   also works with LinuxThreads, untested)
> 
> would you mind explaining why you are using 2 threads? it seems
> pointless, but perhaps i'm missing something...

One is for input and other one is for output. It is especially useful
when input and output goes through different device/driver/hardware and
also for SMP. Just allows simultaneous system calls.

At least it works better for me.. :)


-- 
Jussi Laako <[EMAIL PROTECTED]>

Re: [linux-audio-dev] oss driver for jack 0.90 rev3

[Paul Davis]

> - Conditionally compiled two thread implementation for NPTL (possibly
>   also works with LinuxThreads, untested)

would you mind explaining why you are using 2 threads? it seems
pointless, but perhaps i'm missing something...

[linux-audio-dev] oss driver for jack 0.90 rev3

[Jussi Laako]

Now the oss driver for jack 0.90 starts to shape up. This could be
considered as alpha version.

Changes:

 - Conditionally compiled two thread implementation for NPTL (possibly
   also works with LinuxThreads, untested)
 - Fixed a load of bugs


This version has been tested with CMI8738, ENS1371 and M-Audio
Delta1010. (OSS 3.9.8a)

This version has been tested to work under load up to 8-in, 8-out,
24-bit 96 kHz with period size of 128.


Patch available at http://www.sonarnerd.net/linux/jack_oss.patch
and RPMs and tarball at http://www.sonarnerd.net/linux/


Someone familiar with autoconf/automake could see the
drivers/oss/Makefile.am for some better way of enabling NPTL/barrier
stuff... ;)


-- 
Jussi Laako <[EMAIL PROTECTED]>

[linux-audio-dev] More sequencer engine questions

[Iain Duncan]

Found some good reading material on real time programming and now have a
couple more questions if anyone can share:

- what are the pros and cons for a sequencer engine of using pthreads in one
address space vs seperate processes spawned by one application? Anyone know
what the various linux real time sequencers use?

- if I do POSIX pthreads or multiple processes, will the code be an easy
port to MacOSX? And what about windows, would one be able to run it under
Cygwin or something?

- if I embed another audio app within the project ( looking at embedding
Csound with the Csound API ) is this going to make it much more difficult to
sort out priorities given that Csound kinda has to be allowed to keep
running. I figure it would be second highest priority after the engine

Thanks,
Iain

Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]

[Jussi Laako]

On Mon, 2003-11-17 at 04:06, Jack O'Quin wrote:

> One helpful thing you could do would be testing it on a system with a
> real OSS driver.

I'll test it in near future.

>   Sample Rates = 48000.00, 44100.00, 32000.00, 24000.00, 22050.00, 16000.00, 
> 11025.00,  8000.00,
>   Native Sample Formats = paUInt8, paInt16, 

Maybe this is a feature of alsa oss emulation?


-- 
Jussi Laako <[EMAIL PROTECTED]>

Re: [linux-audio-dev] [PATCH] oss driver for jack 0.90.0 - the actual patch :)

[Jussi Laako]

On Mon, 2003-11-17 at 04:07, Paul Davis wrote:

Thanks for pointing out the errors in code.

>   1) the null cycle callback is wrong. it will generate random noise, and
>should instead generate silence.

OK, fixed...

>   2) the buffer size callback is wrong. you have to stop the hardware,
>reset the period size, and then restart the hardware.

OK, fixed too. Maybe the documentation in driver.h is either incorrect
or misleading or I just understood it wrong.. :)

>   3) is there a reason why you are not using bob's infrastructure for
>APIs without their own thread? it seems wasteful to duplicate
>this again. the OSS driver should be like the ALSA one in this
>respect.

Because of how the newest version of driver is implemented.

> joq is correct that adding a new driver adds a real burden to the
> core JACK team. if you are unwilling to commit to maintaining the
> driver to keep track with other JACK changes, then we should not add
> it to CVS.

It's of course your decision.. However, will it be included or not, I
will continue developing the driver for unspecified amount of time. At
least as long as I have interest, time and there are some interested
users out there... :)


-- 
Jussi Laako <[EMAIL PROTECTED]>

Re: [linux-audio-dev] plugin GUIs

[Steve Harris]

On Tue, Nov 18, 2003 at 02:50:37 -0500, Paul Davis wrote:
> if we avoid the goal of having the host have some control over the
> plugin GUI window, then this isn't necessary, and the design i
> implemented last night will work without any special support from X or
> toolkits. it does require a small library with what steve has termed
> "toolkit specific hacks" - its not so much that as enumeration of
> supported toolkits. however, the goal of the host having some control
> over the plugin GUI window seems rather desirable.

If the host has no control over the UI then I'm not quite sure what the
point is. It saves on processes, but the're pretty cheap on UNIX anyway.

We need some kind of IPC (ITC?) between the host and UI anyway, to handle
serialisation of control changes.

- Steve

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Paul Davis]

>> One important thing to remember - if you like to get broad acceptance
>> you have to suggest a solution that solves these problems. I would say
>> that the rt_monitor or some other means to do the same thing is
>> mandatory to get that kind of acceptance.
>
>I don't (personally) want or need at this point in time for the solution
>to have "broad acceptance", although that would be real nice. I want
>something that enables me to run applications with real time priority
>and memory lock as a normal user. So far the options that target both
>aspects (scheduler and memory lockdown) involve a kernel patch. 

i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.

>Of course there does not have to be just _one_ answer to the question!
>Let's implement both and let the user choose according to his/her/its
>needs :-)

its a few lines of code to be commented in JACK. somebody try it out
(its in jackd/engine.c and libjack/client.c)

--p

Re: [linux-audio-dev] plugin GUIs

[Paul Davis]

>On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote:
>> i offer this as a proof of concept. i believe that our problems with
>> GUIs for plugins are pretty much over, modulo defining some standards
>> as per another recent from me.
>
>Paul,
>
>I freely confess that I do not know how X works.  Can you explain a bit more
>for the dummies (like me) what you've come up with, what it means, and how
>we can use it for the GMPI discussions?

i'm not quite ready for that yet, and trust me i'll post on GMPI once
i am.

what i can say for now is that the XEmbed extension, a relatively
recent extension but present in XFree86 for quite a while, its
designed to allow precisely this to happen in a smooth way. It allows
either of these to be done very simply:

   * host creates window, passes it to the plugin as the "parent"
 window for the plugin's GUI
 
   * plugin creates a window, passes it to the host which
 "parents" it into one of its own toplevel windows.

the plugin/host relationship can be in-process or out-of-process,
XEmbed doesn't care.

the big problem is that at this time only GTK+ has support for
XEmbed. Qt can support it, but its not part of Qt (it lives in kdelibs
instead, as the QXEmbed widget). I doubt if any other toolkits at this
time support it.

i am trying to investigate ways of doing this without XEmbed, which is
said to be possible and was being done in Mozilla a couple of years
ago where they realized they faced the same problems.

if we avoid the goal of having the host have some control over the
plugin GUI window, then this isn't necessary, and the design i
implemented last night will work without any special support from X or
toolkits. it does require a small library with what steve has termed
"toolkit specific hacks" - its not so much that as enumeration of
supported toolkits. however, the goal of the host having some control
over the plugin GUI window seems rather desirable.

--p

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
> On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
> > 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 page reads?)
> > >
> > > Well, I'd say this is the showstopper. We really need this. "Unlikely"
> > > is not enough. Eventually memory will run out and the wrong page will
> > > fault and we get a click. We have to be able to lock memory..
> >
> > Agreed.  IMHO, mlock() is mandatory, certainly for JACK applications.
> 
> 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's one reason why you won't see this done on any general purpose
distribution. Another reason: most (all?) mainstream distributions do
not cater to the "pro audio" users that need very reliable and very low
latency operation. Yet another: it is difficult :-)

> So with any scheme that opens up these holes you have to deliver a way
> to protect from the downsides.

Or not. Sometimes you have to learn to live with them...

> My monitor protects from CPU overuse, but what about memory?
> How to protect from an application that mlockall(MCL_FUTURE) and
> has a memory leak?

Good point. Probably you can't :-(

> One important thing to remember - if you like to get broad acceptance
> you have to suggest a solution that solves these problems. I would say
> that the rt_monitor or some other means to do the same thing is
> mandatory to get that kind of acceptance.

I don't (personally) want or need at this point in time for the solution
to have "broad acceptance", although that would be real nice. I want
something that enables me to run applications with real time priority
and memory lock as a normal user. So far the options that target both
aspects (scheduler and memory lockdown) involve a kernel patch. 

> > The big difference between realtime and most other kinds of
> > performance work is that it focuses on tuning the "worst case", not
> > the average.  Paging works fine on average, but in the worst case your
> > recording session gets blown.
> 
> SCHED_FIFO does not make ANY guarantees on "worst case"!

Correct. We do have xruns every once in a while, it depends a lot on the
hardware and how the system is tuned. If we get real serious, from the
point of view of "worst case", linux is the wrong tool to do realtime
audio processing. Something like QNX would be better (a _real_ realtime
operating system). 

> > Otherwise, a good solution.  Perhaps adequate for some applications.
> 
> But at the same time SCHED_FIFO is adequate for most applications.
> See my point? :-)

I see your point. There is no clearly marked dividing line in either
case. For a certain very high latency requirement SCHED_OTHER, in the
average, is just fine. For the latency expectations of most people in
this list SCHED_FIFO is a good solution (if the kernel is patched for
low latency operation - otherwise it does not work either). If you
really go down in latency, SCHED_FIFO is no longer good enough. This
part at least is clear to me (we _need_ SCHED_FIFO), but equally clear
is the fact that it will not _always_ work (100% of the time). 

So the question about mlockall would be, is it something akin to
SCHED_OTHER? (ie: with it the whole thing is unusable?). Or is it like
SCHED_FIFO? (ie: not 100% perfect but we really need to have it?). 

My feeling is that we need it, but I don't have experimental data to
back it up. 

Any one out there doing experiments with this? Something like: start a
critical audio app with and without mlockall, subject the machine to
high memory loads to force paging (ie: start a lot of applications), see
what happens. 

Of course there does not have to be just _one_ answer to the question!
Let's implement both and let the user choose according to his/her/its
needs :-)

-- Fernando

Re: [linux-audio-dev] plugin GUIs

[Tim Hockin]

On Tue, Nov 18, 2003 at 10:45:40AM -0500, Paul Davis wrote:
> i offer this as a proof of concept. i believe that our problems with
> GUIs for plugins are pretty much over, modulo defining some standards
> as per another recent from me.

Paul,

I freely confess that I do not know how X works.  Can you explain a bit more
for the dummies (like me) what you've come up with, what it means, and how
we can use it for the GMPI discussions?

Tim

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Fernando Pablo Lopez-Lezcano]

On Mon, 2003-11-17 at 19:59, Jack O'Quin wrote:
> To summarize, my proposal is:
> 
>   sysctl -w kernel/realtime=0   # disable realtime privileges
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
> #   for `root' group
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
>   sysctl -w kernel/realtimegroup=-1 #   for every process
> 
>   sysctl -w kernel/realtime=1   # enable realtime privileges
>   sysctl -w kernel/realtimegroup=29 #   for `audio' group
> 
> Only root can write these variables.  If possible, let's agree on a
> standard gid to use for group `realtime', there isn't one now.

Sounds good to me...

Here's a list of uids/gids as used in RedHat (courtesy of Matthias):
  http://freshrpms.net/packages/res/uidgid.html
I seem to remember having read somewhere of an initiative to standarize
all these numbers, can't remember where or when. 

-- Fernando

Re: [linux-audio-dev] and just to finalize ...

[Lance Blisters]

> > i suppose that if i knew this was possible 2 years ago, i would never
> > have written JACK. that's the upside, perhaps. should JACK exist? is
> > the address space isolation worth it? big questions.
> 
> As others have also noted, adress isolation is god sent. Whatever you do, 

chiming in, address isolation is great.  gdam forks processes for
mp3 decoding... if mpg123 crashes, that one song ends early.  with
in-client mpglib a crash would take down the whole app.  for anyone
performing live, in front of audiences, stability and reliablity are
of utmost importance.

  -geoff

Re: [linux-audio-dev] and just to finalize ...

[Robert Jonsson]

Tuesday 18 November 2003 15.22 skrev Paul Davis:
> >I'd like to say: woohoo!
>
> i suppose that if i knew this was possible 2 years ago, i would never
> have written JACK. that's the upside, perhaps. should JACK exist? is
> the address space isolation worth it? big questions.
>

As others have also noted, adress isolation is god sent. Whatever you do, 
unless jack crashes, almost nothing can bring your application down (a mild 
overstatement perhaps *). This is a _major_ feature. 
I also think that jack apps should be easier to design and program as opposed 
to plugin-centric solutions. The boundaries are dictated by the operating 
system, not by the plugin-architecture.

In my mind jack ought to have much better long-term viability than an in-proc 
plugin-system. Today you can probably wring out more precious clock cycles 
from an in-proc system since the overhead isn't as big. But in a few years 
(or already now!) the overhead for this is easily traded for the added 
benefits.

/Robert

* Jack does add a few critera of it's own, can you say ZOMBIE ? ;) But this is 
a necessity with an in-proc system also.

Re: [linux-audio-dev] plugin GUIs

[Maarten de Boer]

> XEMBED style, or "foreign window style" ? i've already learnt how to
> do it with Qt ...

I don't remember.. I did it once. I think it was foreign window style.
Anyway, I'll give it a try tomorrow.

Maarten

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Roger Larsson]

On Tuesday 18 November 2003 13.28, Stefan Nitschke wrote:
> >BUT, I think a userspace daemon that starts at boot time and protects
> >against lockups (rt_monitor) would be a very good thing to have.
>
> Yes indeed, but on my XP machine which freezes after a few seconds
> after a client had connected to jack even rt_monitor did not helped,
> the machine keeped totally locked. Ping is still answered but thats it.
>

ping is answered = IRQs live.
Could you please try this.
Start rt_monitor in a text console CTRL-ALT-F1

Start your client, return to console - what does rt_monitor print?

(It could be the memory leak and mlockall(FUTURE) problem,
As I do not check that yet.
Another alternative is a fast forking client - they are hard to stop)

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

Re: [linux-audio-dev] plugin GUIs

[Paul Davis]

>For what it's worth, this can also be done with FLTK.

XEMBED style, or "foreign window style" ? i've already learnt how to
do it with Qt ...

Re: [linux-audio-dev] plugin GUIs

[Maarten de Boer]

For what it's worth, this can also be done with FLTK.

Maarten

[linux-audio-dev] plugin GUIs

[Paul Davis]

the following is tiny example to show that its possible to use XEMBED
or just native X Window IDs to create host-managed plugin GUIs. GTK+2
and Qt3 both support XEMBED; GTK+2 supports use of native X Window ids
when creating new top level windows, i am not sure about Qt (does
anybody here know how to do it).

this means that a GTK host can manage a Qt GUI or vice versa, without
any toolkit specific hacks in the host or in a library linked by the
host. 

i offer this as a proof of concept. i believe that our problems with
GUIs for plugins are pretty much over, modulo defining some standards
as per another recent from me.

--p

--

#include 
#include 
#include 
#include 

gboolean
button_pressed (GtkWidget *widget,
GdkEventButton *event,
gpointer user_data)
{
fprintf (stderr, "host: button press at %g,%g\n", event->x, event->y);
return TRUE;
}

gboolean
delete_event (GtkWidget* widget,
  GdkEvent* event,
  gpointer user_data)
{
fprintf (stderr, "host: window delete event\n");
gtk_main_quit ();
return TRUE;
}

gboolean
plugin_button_pressed (GtkWidget *widget,
GdkEventButton *event,
gpointer user_data)
{
fprintf (stderr, "plug: button press at %g,%g\n", event->x, event->y);
return TRUE;
}

gboolean
plugin_delete_event (GtkWidget* widget,
  GdkEvent* event,
  gpointer user_data)
{
fprintf (stderr, "plug: window delete event\n");
gtk_main_quit ();
return FALSE;
}

int
plugin_main (GdkNativeWindow window_id)
{
GtkWidget* embedded_parent;
GtkWidget* dummy_label;
GdkWindow* foreign_window;
int argc = 1;
char **argv = (char **) malloc (sizeof (char*));
argv[0] = "plugin";

gtk_init (&argc, &argv);

#ifdef USE_XEMBED
embedded_parent = gtk_plug_new (window_id);
#else
embedded_parent = gtk_window_new (GTK_WINDOW_TOPLEVEL);
foreign_window = gdk_window_foreign_new (window_id);
gtk_widget_set_parent_window (embedded_parent, foreign_window);
#endif

dummy_label = gtk_label_new ("This is a LADSPA Plugin GUI");

gtk_container_add (GTK_CONTAINER(embedded_parent), 
   dummy_label);


gtk_signal_connect (GTK_OBJECT(embedded_parent),
"button-press-event",
GTK_SIGNAL_FUNC (plugin_button_pressed),
NULL);

gtk_signal_connect (GTK_OBJECT(embedded_parent),
"delete-event",
GTK_SIGNAL_FUNC (plugin_delete_event),
NULL);

gtk_widget_add_events (GTK_WIDGET (embedded_parent), 
   GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK);

gtk_widget_show (embedded_parent);
gtk_widget_show (dummy_label);
}

int
main (int argc, char *argv[])
{
gtk_init (&argc, &argv);

GtkWidget* embedded_parent;
GtkWidget* embedded_window;

embedded_window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

#ifdef USE_XEMBED
embedded_parent = gtk_socket_new ();

gtk_container_add (GTK_CONTAINER(embedded_window),
   embedded_parent);
gtk_widget_show (embedded_parent);
#endif  

gtk_signal_connect (GTK_OBJECT(embedded_window),
"button-press-event",
GTK_SIGNAL_FUNC (button_pressed),
NULL);

gtk_signal_connect (GTK_OBJECT(embedded_window),
"delete-event",
GTK_SIGNAL_FUNC (delete_event),
NULL);

gtk_widget_add_events (GTK_WIDGET (embedded_window), 
   GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK);
gtk_widget_set_size_request (GTK_WIDGET(embedded_window), 100, 100);
gtk_window_set_title (GTK_WINDOW(embedded_window), "A Plugin");

gtk_widget_show (embedded_window);
gtk_widget_realize (embedded_window);

#ifdef USE_XEMBED
plugin_main (gtk_socket_get_id (GTK_SOCKET(embedded_parent)));
#else
plugin_main (GDK_WINDOW_XID (embedded_window->window));
#endif
gtk_main ();
}

Re: [linux-audio-dev] cross-toolkit host/plugins: significant news

[Fred Gleason]

On Tuesday 18 November 2003 02:14, Paul Davis wrote:

> to put in bluntly, it appears that i have been totally and utterly
> full of crap, and have unnecessarily delayed the advent of decent
> plugin GUIs on linux by a year or more.

So, book yourself a guilt trip, and when you return, life will go on...  :)


> i hate the way Qt takes over the build process. It reminds me too much
> of Oracle in this respect. 

It's not that difficult to build Qt apps without resorting to Qmake.  I 
typically do the following in Makefile.am:

# Define the dependency for the Meta Object Compiler
MOC = $(QTDIR)/bin/moc
moc_%.cpp:  %.h
$(MOC) $< -o $@

# Then, lay out the dependencies like so:
bin_PROGRAMS = myprog
dist_myprog_SOURCES = myprog.cpp myprog.h
nodist_myprog_SOURCES = moc_myprog.cpp
myprog_LDADD = -lqui

This will work with vanilla Autoconf/Automake, and will ensure that the MOC 
gets called at the correct time, while also autocleaning the MOC output when 
building dists and such.  It does require that your environment contain the 
path to your Qt installation in QTDIR, but that is a standard part of a 
"correct" Qt installation, as per Trolltech.

Oh, and thank you, Paul.  The work you do is *very* appreciated around here...

Cheers!


|-|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development  |
|   | Salem Radio Labs|
|-|
|  No woman can endure a gambling husband, unless he is a steady winner.  |
|-- Lord Thomas Dewar |
|-|

Re: [linux-audio-dev] and just to finalize ...

[Alfons Adriaensen]

On Tue, Nov 18, 2003 at 09:22:13AM -0500, Paul Davis wrote:


> i suppose that if i knew this was possible 2 years ago, i would never
> have written JACK. that's the upside, perhaps. should JACK exist? is
> the address space isolation worth it? big questions.


JACK should definitely exist, but it could be in a form that only
allows 'in-process' clients. This would put the inter-process
interface between the audio code and the GUI, were it is possibly a
lot less critical. I've always preferred this model, and in fact
use it in all my professional work. The hard work of creating a
lock-free (from the audio side) control and monitoring interface
is done by library code. If you use IP sockets between the two
parts (as we do here), you can even put the real-time code on a
dedicated compute server. As a nice side effect, such a model more
or less imposes an MCV architecture, which is also a good thing (TM).
For a large organisation as the one I work for, such an architecture
also permits separate development of the signal processing and the
GUI code. We always use a text format interface between the two parts,
so you can telnet to the DSP code and control it without the GUI.

The hard work with this approach is defining all the messages that
form the interface between the DSP code and the GUI. You really
need to do this before starting to work on the code itself. OTOH,
this means you start off with a very clear analysis of you
application.

-- 
FA

Re: [linux-audio-dev] and just to finalize ...

[Steve Harris]

On Tue, Nov 18, 2003 at 09:22:13 -0500, Paul Davis wrote:
> >I'd like to say: woohoo!
> 
> i suppose that if i knew this was possible 2 years ago, i would never
> have written JACK. that's the upside, perhaps. should JACK exist? is
> the address space isolation worth it? big questions.

In that case its a good thing. Having spoken to people who've worked with
the windows version of rewire, the address space isolation is very
important.

If there was an expectation (or requirement) for nice, author provided UIs
for plugins, do you think there would be so many for linux now?
 
> >What are the arguments against stuffing the UI code in the same .so file?
> 
> what happens if you wanted a different GUI for the same plugin? well,
> personally i think this is too much of an edge case - people who want
> to do this can learn to recompile/relink. so i'd be fine with putting
> it in the same .so file.

People who want to do this can define a service discovery mechanism
(service discovery is my least favourite problem at the moment). They may
want it to be network transparent, or platform neutral or something.

> >> 2) the GUI would have to declare which toolkit it was using so that
> >>the host could ensure support for it (i.e. fire up a thread that
> >>will run the equivalent of gtk_main or QApplication::exec()) and
> >>ask the relevant toolkit thread to call the primary entry point to
> >>the GUI. how does it declare this? a well known symbol? is it a
> >>char* or a function call? is it in the LRDF entry, or the filename,
> >>or what?
> >
> >This can be wrapped in a non toolkit specific library, right? Cant most of
> >this be handled by the plugin UI?
> 
> the library has to be (dynamically) linked against every toolkit for
> which it offers support. the host uses the library to open the plugin
> GUI. the host has to do something like:

Ugh, this is looking less good.

> >I'm not clear on the specifics of how this all works, but the host may
> >well want to swallow the plugin window(s) and max/minimise it and so on.
> 
> it appears to me this morning that the XEmbed protocol is in fact
> exactly what is called for here, and will work for at least GTK+ and
> Qt. i'm going to write a short demo.

Yes, from what I remember XEmbed is good for this kind of stuff, if only
GTK and QT atr supported that would be a pain, but maybe worth it

- Steve

Re: [linux-audio-dev] and just to finalize ...

[Paul Davis]

>I'd like to say: woohoo!

i suppose that if i knew this was possible 2 years ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.

>What are the arguments against stuffing the UI code in the same .so file?

what happens if you wanted a different GUI for the same plugin? well,
personally i think this is too much of an edge case - people who want
to do this can learn to recompile/relink. so i'd be fine with putting
it in the same .so file.
 
>> 2) the GUI would have to declare which toolkit it was using so that
>>the host could ensure support for it (i.e. fire up a thread that
>>will run the equivalent of gtk_main or QApplication::exec()) and
>>ask the relevant toolkit thread to call the primary entry point to
>>the GUI. how does it declare this? a well known symbol? is it a
>>char* or a function call? is it in the LRDF entry, or the filename,
>>or what?
>
>This can be wrapped in a non toolkit specific library, right? Cant most of
>this be handled by the plugin UI?

the library has to be (dynamically) linked against every toolkit for
which it offers support. the host uses the library to open the plugin
GUI. the host has to do something like:

 switch (plugin->toolkit_id) {
 case PLUGIN_GUI_GTK_2:
  return load_gtk2_plugin (plugin_handle);
  
 case PLUGIN_GUI_QT3:
  retur load_qt3_plugin (plugin_handle);
 
   ...
 }

think of it was a "factory method" in OOP.
 
>> 6) [ only if we really wanted hosts to have a "real" handle on the
>>plugin GUI window ] the library would need to contain a way to
>>pass in an X "Window", and wrap it up as a native drawing area
>>for each toolkit. i would prefer not to do this for now, if ever.
>
>I'm not clear on the specifics of how this all works, but the host may
>well want to swallow the plugin window(s) and max/minimise it and so on.

it appears to me this morning that the XEmbed protocol is in fact
exactly what is called for here, and will work for at least GTK+ and
Qt. i'm going to write a short demo.

--p

Re: [linux-audio-dev] and just to finalize ...

[Paul Davis]

>> 6) [ only if we really wanted hosts to have a "real" handle on the
>>plugin GUI window ] the library would need to contain a way to
>>pass in an X "Window", and wrap it up as a native drawing area
>>for each toolkit. i would prefer not to do this for now, if ever.
>
>What about reparenting the window like the window manager does? 
>  I must confess: I don't know anything about programming this 
>but have "heard" about the concept.  AFAIK, any window can be 
>absorbed by a container -- but I don't know what this really and 
>programmatically means.  So it's just an idea ...

the problem is getting the GUI toolkit to use an externally created
window to parent one of its own. i wouldn't want to rely on XEMBED for
this, and there is probably no need to. i know that GDK has
gdk_window_new_foreign(), which does 50% of the work. don't know about
Qt, but i will check.

--p

Re: [linux-audio-dev] and just to finalize ...

[Steve Harris]

I'd like to say: woohoo!

On Tue, Nov 18, 2003 at 02:23:05 -0500, Paul Davis wrote:
> what would all this mean for LADSPA?
> 
> 1) there would need to be a way to associate plugins+GUIs since we
>probably don't want them in the same object.
> 
>  - could be done using LRDF or a dir search path combined with the
>plugin ID.

I vote for the latter, otherwise the fully qualified GUI path would have
to be in the metadata, which seems a bit odd.

What are the arguments against stuffing the UI code in the same .so file?
 
> 2) the GUI would have to declare which toolkit it was using so that
>the host could ensure support for it (i.e. fire up a thread that
>will run the equivalent of gtk_main or QApplication::exec()) and
>ask the relevant toolkit thread to call the primary entry point to
>the GUI. how does it declare this? a well known symbol? is it a
>char* or a function call? is it in the LRDF entry, or the filename,
>or what?

This can be wrapped in a non toolkit specific library, right? Cant most of
this be handled by the plugin UI?
 
> 6) [ only if we really wanted hosts to have a "real" handle on the
>plugin GUI window ] the library would need to contain a way to
>pass in an X "Window", and wrap it up as a native drawing area
>for each toolkit. i would prefer not to do this for now, if ever.

I'm not clear on the specifics of how this all works, but the host may
well want to swallow the plugin window(s) and max/minimise it and so on.

- Steve

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Stefan Nitschke]

BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to jack even rt_monitor did not helped,
the machine keeped totally locked. Ping is still answered but thats it.
- Stefan

_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

[linux-audio-dev] Ann. Vstserver V0.2.8 and Ladspavst V0.1.5

[Kjetil Svalastog Matheussen]

These updates makes it possible to use windows vst plugins in
linux applications getting very descent realtime performance.

I have successfully ran vst plugins in ardour with 2.66 ms latency.

Sources:
http://www.notam02.no/arkiv/src/

Linux Vst Compatibility Page
http://80.61.20.184/vst/

Tutorial:
http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/

Mandrake binaries: (not the latest versions (yet))
http://rpm.nyvalls.se/sound9.1.html



Vstserver 0.2.7 -> 0.2.8:
-
-Added SCHED_FIFO priority and locking all mem (mlockall) to the
 processing thread. Can be used without being root by for example
 using the givertcap program by Tommi Ilmonen
 http://www.tml.hut.fi/~tilmonen/givertcap/
 To turn off realtime priority, start the vstserver with either
 the "-NRT" or "--nonrealtime" flag.


vst ladspa plugin v0.1.5 - stable
--
-Fixed the worst nonrealtimeness for the default mode.
 When using realtime priority on the vstserver, it
 should not be necesarry to set LADSPAVST_RT to "1".



-- 

Re: [linux-audio-dev] and just to finalize ...

[Uwe Koloska]

Paul Davis wrote:

what a night (paul simon on the famous A&G concert in central park)
6) [ only if we really wanted hosts to have a "real" handle on the
   plugin GUI window ] the library would need to contain a way to
   pass in an X "Window", and wrap it up as a native drawing area
   for each toolkit. i would prefer not to do this for now, if ever.
What about reparenting the window like the window manager does? 
 I must confess: I don't know anything about programming this 
but have "heard" about the concept.  AFAIK, any window can be 
absorbed by a container -- but I don't know what this really and 
programmatically means.  So it's just an idea ...

Uwe

--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany

[linux-audio-dev] and just to finalize ...

[Paul Davis]

what would all this mean for LADSPA?

1) there would need to be a way to associate plugins+GUIs since we
   probably don't want them in the same object.

 - could be done using LRDF or a dir search path combined with the
   plugin ID.

2) the GUI would have to declare which toolkit it was using so that
   the host could ensure support for it (i.e. fire up a thread that
   will run the equivalent of gtk_main or QApplication::exec()) and
   ask the relevant toolkit thread to call the primary entry point to
   the GUI. how does it declare this? a well known symbol? is it a
   char* or a function call? is it in the LRDF entry, or the filename,
   or what?

3) adopt a standard for how the entry point is to be
   called. presumably it should get a pointer to the plugin instance,
   but what (if anything) else? oh yes, a return value that provides
   a way to terminate the GUI.

4) the names of toolkits would have to be standardized and possibly
   include version information. "GTK+:2.2" or "Qt:3.1" might work, for
   example.

5) a small library (which i have more or less started already) to
   provide simple C functions to offer per-toolkit support. a host
   would look at the pluginGUI toolkit, call the support function
   with the .so name, and the right things would happen. the library
   needs an ancillary function to kill the GUI when the time is
   right. 
   
6) [ only if we really wanted hosts to have a "real" handle on the
   plugin GUI window ] the library would need to contain a way to
   pass in an X "Window", and wrap it up as a native drawing area
   for each toolkit. i would prefer not to do this for now, if ever.

--p
   

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

[Roger Larsson]

On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
> 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 page reads?)
> >
> > Well, I'd say this is the showstopper. We really need this. "Unlikely"
> > is not enough. Eventually memory will run out and the wrong page will
> > fault and we get a click. We have to be able to lock memory..
>
> Agreed.  IMHO, mlock() is mandatory, certainly for JACK applications.

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)
So with any scheme that opens up these holes you have to deliver a way
to protect from the downsides.
My monitor protects from CPU overuse, but what about memory?
How to protect from an application that mlockall(MCL_FUTURE) and
has a memory leak?

One important thing to remember - if you like to get broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.

>
> The big difference between realtime and most other kinds of
> performance work is that it focuses on tuning the "worst case", not
> the average.  Paging works fine on average, but in the worst case your
> recording session gets blown.

SCHED_FIFO does not make ANY guarantees on "worst case"!

>
> Otherwise, a good solution.  Perhaps adequate for some applications.

But at the same time SCHED_FIFO is adequate for most applications.

See my point? :-)

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

[linux-audio-dev] cross-toolkit host/plugins: significant news

[Paul Davis]

its been a productive evening/night. or has it?

i hacked up a small test that runs Qt as a host, and loads a shared
object that uses GTK+ as its GUI. the host loads the shared object,
and runs its GUI, in addition to its own. cool, eh?

well, not so fast. i am now wondering what in the hell all the fuss
was about in the first place. and as the main progenitor of "you can't
do this", i feel responsible for cleaning up the mess.

why? i don't see anything in what i've done that is at all clever. the
only slightly tricky part is running the GTK+ GUI in its own thread,
and routing requests to instantiate a new GUI to that thread via a
pipe that is hooked into the GTK+ event loop. i can't see any reason
why *any* toolkit couldn't be used in this way (assuming it can do
this kind of "add an fd to the event loop" thing, and AFAIK they all
can). i even removed all the stuff i added to open a dedicated X
Display - it just isn't necessary. Qt and GTK+ both have their own
connection to the X Server, and there are separate event loops
handling windows created by each toolkit, each running in its own
thread. all you have to avoid is a plugin calling QApplication::exec()
or gtk_main() etc., which will different and odd effects on each
toolkit. 

AFAICT, there are two things the host can't really do. one is to snoop
on events for other toolkit's loops. so, a host that relies on
snooping keyboard events (e.g. ardour) is out of luck when it comes to
events occuring in plugin GUI windows using a non-host-toolkit. the
host also cannot get access to the toplevel windows of the
non-host-toolkit, so it can't add the kind of generic widgets that you
tend to see on TDM/VST plugin GUIs for "bypass", "save" and so forth.

but to return to the core issue here. what the f*ck have i been
ranting on about all this time?  unless its just the issue of globals
in Xlib, but i really don't believe they are there anymore, at least
not in XFree86 ... yes, the toolkits can't share an X Display, but fer
chrissakes! they don't even try to!!

to put in bluntly, it appears that i have been totally and utterly
full of crap, and have unnecessarily delayed the advent of decent
plugin GUIs on linux by a year or more.

if anybody wants to see the code for my little demo, i'll tar it up. i
hate the way Qt takes over the build process. It reminds me too much
of Oracle in this respect. Anyway, i need to get to bed. I feel glad
that this can be made to work, but embarrased about what i may have
done here.

--p