49 lines
2.2 KiB
HTML
49 lines
2.2 KiB
HTML
<HTML>
|
|
<BODY>
|
|
|
|
<H1>Misc notes</H1>
|
|
|
|
<UL>
|
|
|
|
<LI><P><B>MPU401 kernel module.</B> If your soundcard supports MIDI input and
|
|
output, chances are that it is powered by an MPU401 chip. Because this
|
|
interface is so popular, BeOS comes with a kernel module that makes it easy to
|
|
write drivers for the MPU401. Thanks to Greg Crain, we now have an open source
|
|
version of this kernel module.</P>
|
|
|
|
<P>The mpu401 module lives in <CODE>src/add-ons/kernel/generic/mpu401</CODE>.
|
|
It supports both the v1 and (undocumented) v2 protocols, although v2 is not
|
|
complete since we don't really know how it works. Unfortunately, almost no
|
|
existing drivers use v1; most of the drivers provided by Be require v2.
|
|
Currently, the module returns B_ERROR when a MIDI device is opened with
|
|
v2.</P>
|
|
|
|
<P>For an example on how to use the MPU401 module in your own driver, see
|
|
the source code for the "emuxki" driver elsewhere in the source tree.</P></LI>
|
|
|
|
<LI><P><B>Clients without a BApplication.</B> Sometimes the midi_server's
|
|
debug output shows an "Application -1 not registered" error message. This
|
|
means it cannot figure out which app an incoming BMessage came from. The
|
|
server ignores those messages.</P>
|
|
|
|
<P>How can this happen? libmidi2 has two ways of sending messages to the
|
|
midi_server: it either expects a reply back or not. In the first case, it is
|
|
obvious to the midi_server what the reply address of the message is. In the
|
|
second case, even though it is not necessary for the server to send a message
|
|
back, it still uses the reply address to determine which app the message came
|
|
from. For this, BMessenger uses be_app_messenger of the client app.</P>
|
|
|
|
<P>However, if the client app has no BApplication object, there is no
|
|
be_app_messenger either. Now, the midi_server cannot determine where the
|
|
message came from and will ignore it. Is this important? For example, when such
|
|
a client app Release()'s its endpoints, it sends a message to the server
|
|
without a return address. Now the server ignores that message and does not
|
|
remove the endpoint from the roster. Of course, after the client app has died,
|
|
the endpoints will be removed eventually. Does all of this matter? Not really,
|
|
because only trivial apps will have no BApplication object.</P></LI>
|
|
|
|
</UL>
|
|
|
|
</BODY>
|
|
</HTML>
|