Subject: Re: [linux-audio-dev] discussion about development overlap
From: Stephane Letz (letz_AT_grame.fr)
Date: Thu Sep 28 2000 - 12:08:37 EEST
>I hope that the midishare code is flexible enough to be transformed
>into a pur e userspace midishare server for my proposed rtsoundserver
>model (must audio and MIDI). Audio routing would be useful too so
>that several "clients" (aka plugins) could get/send audio from/to
>various sources which can be real input/outputs or other clients.
The current published MidiShare version (http://www.grame.fr/MidiShare/)
is the Midi one. MidiShare is separated in a kernel module and a shared
library in user space.
The kernel module contains :
- the Midi events sorting, routing, dispatching code
- the scheduler (using currently a 100 Hz system timer task, that is 10
times too slow)
- the "real-time" (lock-free freelist based) Midi event memory manager in
kernel space
The user space libabry contains:
- the ioctl code to access the kernel entry points
- the "real-time" (lock-free freelist based) Midi event memory manager in
user space
Midi events sent from a user space application are copied into the kernel,
inserted in the sorter, and dispatched to the destination applications when
they are ready using the current connection scheme between applications.
Midi drivers are currently developed as a user space application that parse
a raw midi stream (read on /dev/midi) and produce structured MidiShare
events (and the contrary).
MidiShare on Linux does not contain synchronisation code yet. (On the Mac
version, the MidiShare time can be synchronised on a external SMPTE
source). Doing that on Linux requires to have first a faster interrupt
source (1000 hz) that need probably to be done using a RTC source or a
audio based timer.
MidiShare does not have a musical time representation (and so no Midi
clock/SPP sycnhronisation mechanism). This is usually done at the library
level.
The CVS server for MidiShare source code is at
http://cvs.grame.fr/cgi-bin/midishare-cvs/
The web page for the kernel development is at:
http://www.grame.fr/MidiShare/SCPP/KDG/KDGFrames.html
The web page for the MidiShare API is at:
http://www.grame.fr/MidiShare/Doc/MidiShare_doc.html
>it has a GUI to hook things up, and the connections can be
>many-to-one, one-to-many as well as one-to-one.
The MidiShare kit contains a set of basic applications
http://www.grame.fr/MidiShare/Using/StdTools.html
msConnect is the standard tool to dynamically set up connections between
running applications.
I doubt that the
>latency is really good enough for real-time performance with a
>soft-synth, but it looked pretty great for everything else.
To improve latency, we need first to have a higher frequency interrupt
(1000 hz) for the whole system.
>>
>right, this is the "audio ALSA sequencer" thing, AKA "audio routing in
>MidiShare". Please note that MidiShare can do all this stuff, at least
>the development version, though I don't know what the latency issues
>are.
>
Audio routing in MidiShare (the demo at LSM) is an experimental
developement where audio streams are transmited between applications in the
form of successives time-stamped "audio events". The audio in driver cut a
continuous stream (read on /dev/dsp) into audio events and dispatch them to
all connected applications. The audio out driver mix audio events received
from all connected application and produces a continuous stream (written on
/dev/dsp). Audio events contain audio-buffer allocated in a shared memory
area.
A basic implementation is working but of course is limited by the standard
problems (latency, context switch cost, real-time thread management....)
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr
This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 13:19:05 EEST