session management API (was Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: session management API (was Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer)
From: Likai Liu (news_AT_likai.net)
Date: Thu Aug 22 2002 - 16:49:31 EEST


mikko.a.helin_AT_nokia.com wrote:

>Anyway (IMHO), there should really be an API which combines audio and MIDI playback
>
mostly if you design an api with both midi and audio support, you would
want to isolate the audio part and the midi part as much as possible
because someone who develops a program that deals with audio and not
midi really doesn't want to deal with midi at all (or vice versa). so
your api design would have the audio and midi sufficiently independent
of each other. the end result is much like mixing alsaseq library, jack,
and perhaps ladspa, and just call them altogether "lapi" (linux audio
programming interface).

there should be a nice addition to this gang, session management. this
is discussed before on the list. is anybody currently working on this?
I'm thinking of an event (callback) based approach that is very similar
to jack (in fact I think I might just take some code from it
too)--except it won't have to be real time. this shouldn't conflict with
jack--the run() for jack should be run in a dedicated audio thread,
which session manager also provides a run() that maybe should be run in
its own thread as well. the session management system will allow a
program to enumerate sessions that are currently open system wise (by
the same user), and allow a program to "opt in" for being session
managed. the session should record the name/numbering of jack/alsaseq
ports and try to restore them when loading a session. this is just an idea.

this should be called "sam" (session application manager or sam
application manager). i think sam and jack will make good friends.

we don't want to use session management in gnome or kde for a few reasons:

(1) gnome/kde sessions treat the entire desktop environment as one
entity, but it's nice to have different projects working at the same
time and saved in a sense independent of each other.
(2) what about command line programs or Xlib programs?
(3) it is a pain to transfer session of gnome/kde. we don't want to dig
into gnome/kde's private configuration areas and try to extract the
things we need.

liulk


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 16:46:37 EEST