Great to know from Don Gaffney that a joystick works with RTL 1.1 and linux
3.0.36 for "a real-time task to control the output of
a DIO and an AO board in conjunction with a custom scientific
instrument." Does this let you control devices without the intermediary of
DAQ boards and such? Are your devices connected to a standard 15-pin MIDI
port? How is the MIDI port connected to the bus? Does it use any special
timer chip? David (or anyone), how does the precision of standard MIDI
timing relate to RTL's?
David Oronoff (Audiality) is asking for thoughts about potential uses of
joystick/MIDI ports. The kind of thing Don has done could make Real-time
control of joystick/MIDI really handy. I'd heard that:
Joystick/MIDI ports can be used for control with I/O of numbers of
audio AND other devices. Available are MIDI signals of:
+ distinguishable off/on for each note (12 semitones x 12 octaves => 24
[six-setting]state switches), "notes" being routinely re-mappable,
+ [discretized] "continuous" values (loudness, pitch bend),
+ specialized types (used for vibrato etc. in original use),
+ "channel" and rule-set selectors....
MIDI timing has to be precise, and is synchronizable (with MIDI Time
Code MTC, or SMPTE with relative intervals; code shows it's based on system
clock). This makes for an interesting relation with RTL.
--- I've extracted some info about how joystick/MIDI ports pass and time
data below. Found it in Shaun Hargreaves' documentation of his djgpp/gcc
package Allegro for animation/game programming. Shaun notes that in
Allegro, MIDI info sequestered in memory is accessed via interrupt handlers;
tick rate shifts are used; but an audio stream can't be called from "a timer
handler" -- which is what RTL seems to be in some sense, though Don's stuff
works.
**Maybe someone who understands RTL well could compare them for us.**
Thanks!
SC [EMAIL PROTECTED]
++++++++++++++++++++++++++++++++
(Allegro.txt v. 3.0 12/97)
...
Getting input from the PC joystick is not a pleasant task. Not because it is
particularly complicated, but because it depends on a high-precision timing
loop, and the exact results of this can vary depending on the type of
joystick, the speed of your computer, the temperature of the room, and the
phases of the moon. If you want to get meaningful input you have to
calibrate [every endpoint].... ...
============ Timer routines ============...
The standard PC clock only ticks 18.2 times a second, which is not much good
for fast action games. Allegro can replace the system timer routine with a
custom one, which reprograms the clock for higher tick rates while still
calling the BIOS handler at the old speed. You can set up several virtual
timers of your own, all going at different speeds, and Allegro will
constantly reprogram the clock to make sure they are all called at the
correct times. Because Allegro alters the PIT timer chip settings, it should
not be used together with the uclock() function from the djgpp libc.
...
============ MIDI routines [of Allegro] ============
extern void (*midi_msg_callback)(int msg, int byte1, int byte2);
extern void (*midi_meta_callback)(int type, unsigned char *data, int length);
extern void (*midi_sysex_callback)(unsigned char *data, int length);
Hook functions allowing you to intercept MIDI player events. If set to
anything other than NULL, these routines will be called for each MIDI
message, meta-event, and system exclusive data block respectively. They
will execute in an interrupt handler context, so all the code and data
they use should be locked, and they must not call any operating system
functions. In general you just use these routines to set some flags and
respond to them later in your mainline code.
Allegro sourcecode MIDI.c shows this lock_midi calling _go32_dpmi_lock_data
which allegro.h says to get from djgpp/gcc or from linux LOCK_VARIABLE(x) :
/* hook functions */
void (*midi_msg_callback)(int msg, int byte1, int byte2) = NULL;
void (*midi_meta_callback)(int type, unsigned char *data, int length) = NULL;
void (*midi_sysex_callback)(unsigned char *data, int length) = NULL;
/* lock_midi:
* Locks a MIDI file into physical memory. Pretty important, since they
* are mostly accessed inside interrupt handlers.
*/
void lock_midi(MIDI *midi)
{
int c;
_go32_dpmi_lock_data(midi, sizeof(MIDI));
for (c=0; c<MIDI_TRACKS; c++)
if (midi->track[c].data)
_go32_dpmi_lock_data(midi->track[c].data, midi->track[c].len);
}
]
=== Audio streaming uses ring of buffers, LZSS compression ========
void *get_audio_stream_buffer(AUDIOSTREAM *stream);
You must call this function at regular intervals while an audio stream is
playing, to provide the next buffer of sample data (the smaller the
stream buffer size, the more often it must be called). If it returns
NULL, the stream is still playing the previous lot of data, so you don't
need to do anything. If it returns a value, that is the location of the
next buffer to be played, and you should load the appropriate number of
samples (however many you specified when creating the stream) to that
address, for example using an fread() from a disk file. After filling the
buffer with data, call free_audio_stream_buffer() to indicate that the
new data is now valid. Note that this function should not be called from
a timer handler...
a fast buffered file I/O system, which
supports the reading and writing of compressed files using a ring buffer
algorithm based on the LZSS compressor by Haruhiko Okumura. This does not
achieve quite such good compression as programs like zip and lha, but
unpacking is very fast and it does not require much memory.
===================
[EMAIL PROTECTED]
Dr. S. Candelaria de Ram
At 06:40 PM 13-07-1999 +0200, you wrote as our ...Audiality hacking! :-)
>2) Have anyone tried using a standard PC joystick while
> running RTL tasks? The old busy waiting method of
> reading the simple capacitor interfaces probably
> won't work too well... I haven't looked carefully
> into this, and I'm not even sure this method is still
> used, but I will have a look, unless someone already
> knows the facts.
>
> Personally I don't care much, as I could work around
> it (hook an ADC with MUX on some port or something)
> if I really need to play games while running my RT
> stuff, but if RTL gets into the main source tree, and
> RT drivers with special cool features for normal end
> users start to show up, this and possibly other
> similar things might cause trouble...
>
> Facts, ideas, anyone...?
>
>
>//David
I haven't had any problems using the Linux joystick driver
1.2.13 (from Vojtech Pavlik) with RTL 1.1 (2.0.36 kernel).
I've been testing with a cheap analog joystick.
This is used with a real-time task to control the output of
a DIO and an AO board in conjunction with a custom scientific
instrument.
-Don
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
