Re: The first version of Milestone 3
Philippe Houdoin <[email protected]> Mon, 13 Jan 2003 12:43:41 +0100 (CET)
| Newsgroups | gmane.os.openbeos.midi |
|---|---|
| Message-ID | <[email protected]> |
Matthijs wrote: >> - Automatic creation for all entry in /dev/midi/ > > I guess that the midi_server should recognize new devices being > added and old ones being removed. Absolutly, it's a mandatory feature. > So it needs to create/delete > endpoints on-the-fly. Is that indeed possible? By nodes monitoring the /dev/midi/... sub-trees, yes. > Philippe, is that what the device_watcher thing is for? Well, yes and no: it may be possible, but not in the best integrated way. According to my file:///boot/home/config/settings/device_watcher settings file, the BeOS R5's device_watcher *server* simply monitor each /dev/... sub-trees given in there and, when a change (added or removed entry) raise, run the specified program. The program will find two arguments: - first argument will be the kind of event: "added" when a new entry appears somewhere under the subtree "removed" when a entry disappears from the subtree - second argument is the added or removed entry full path So, yes, you can add a "/dev/midi /boot/beos/system/servers/midi_server" line in the device_watcher settings file and add to midi_server the code in midi_server BApplication::ArgsReceived() method to handle the device_watcher notification call, but: - it'll works only if midi_server app is set to B_SINGLE_LAUNCH. No real an issue, as it should be the case. - it makes midi_server dependent on a second app "device_watcher" to run, which is not a good design - worse, under R5, device_watcher is started at boot time only if a PCMCIA bus is detected! I guess it's why Be choosed to implement /dev/midi/* devices monitoring directly in midi_server, via the watch_node() API. Hence these *Watcher classes in midi_server: $ nm --demangle /boot/beos/system/servers/midi_server | grep Watcher DevDirWatcher MidiDevWatcher MidiDevWatcherLooper > Also, do drivers have a way to report their latency? If so, you need > to snooze_until(time - latency) in MidiPortConsumer::Data(). I don't know of any way midi drivers could/should report their I/O latencies. It's up to midi_server MidiPortProducer/Consumer to compute them dynamicly in real time, based on usage. However, this important feature could be added to midi_server when all basics features are there. -Philippe