|
Be Newsletter
Issue 61, February 19, 1997
Table of Contents
BE ENGINEERING INSIGHTS: Tools to Help with Extermination
By Mani Varadarajan
While there is a vast variety of styles of programming,
there are essentially only two styles of debugging. Some
programmers prefer to pepper their code with hundreds of
printf() statements rather than ever using a symbolic
debugger (Benoît Schillings, the author of our Application
Server, is foremost among these); others scoff at such
scaffolding, morally convinced that printf() debugging is
the height of inelegance. Most application writers use a
combination of both, depending on the task.
With the advent of the GUI and window-based applications,
printf()-style debugging naturally became harder. Where does
debugging output go for applications not launched from a
shell? Currently, the only solution in the BeOS is to make
sure that serial debugging output is enabled and that you
use the SERIAL_PRINT() call to see your messages on an
attached terminal. In the unfortunate circumstance where you
don't have a spare serial terminal, you're plumb out of
luck. You have to fashion another method of saving your
debugging output.
Even for programs launched from the shell, viewing debugging
messages from within the shell can get very confusing. For
one, debugging messages can get mixed up with real program
output. Furthermore, in a multithreaded application, unless
the application writer goes to great lengths to record the
thread ID in every message, making sense of which thread
spit what out can give you a migraine.
As a solution to some of these problems, DR9 of the BeOS
will include a "syslog_daemon," which provides the facility
to log messages of all sorts -- from applications, servers,
and the kernel -- to a file. By default each message gets a
time stamp; the daemon can also log the caller's thread ID
and an identifier string. Furthermore, each message can be
given a priority.
For example, simple, informational debugging messages should
be given the priority LOG_DEBUG; more critical messages,
such as severe errors or application panics, should be given
a higher priority, such as LOG_ALERT or LOG_PANIC.
Developers can then set a preference for which priority
messages they want to log. If you're interested only in
severe errors, for example, you wouldn't want to be bothered
by ordinary debugging messages.
As the name suggests, the syslog_daemon is inspired by a
similar service in the UNIX world. syslog_daemon is a simple
Be application that sits waiting for Be messages and
conditionally writes them to a file, serial port, or the
standard error stream.
The API for using syslog_daemon is identical to its UNIX
counterpart, except for multithreaded extensions. Here's an
outline of the routines:
openlog_team and openlog_thread set up default logging behavior. They
take the arguments: (ident, options, facility).
log_thread, log_team, and syslog take printf()-style specifiers and fire
a message off to the syslog_daemon. They take the arguments: (options, format
string, ...).
setlogmask_team and setlogmask_thread set which messages to mask on a
priority basis. They take the argument: (prioritymask).
closelog_team and closelog_thread end a logging session.
logger is a command-line routine to use in shell scripts.
The routines are grouped by team or thread, because it's
sometimes desirable to report messages on a per-team basis
rather than on a per-thread basis. The bare routines
openlog(), syslog(), setlogmask(), and closelog() default to
the per-thread functions.
The openlog calls are optional; if the program doesn't call
openlog itself, the first call to the logging routine will
implicitly call it. Openlog just allows the programmer to
set up default options (such as thread ID logging, serial
port output, and so on) and an identifier string for all
logged messages from the thread or team. "Facility" is a
predetermined classification used by the syslog_daemon;
facilities include the kernel, user programs, servers, the
syslog_daemon itself, and so on.
The log_thread, log_team, and syslog() functions are the
moral equivalents of printf() and accept all the same
specifiers.
The messages are logged as follows:
Feb 13 13:14:49 'ftpd'[145]: received 1000 bytes
Feb 13 13:15:01 'thread1'[200]: got here! yeah!
Feb 13 13:15:05 'thread1'[200]: Waiting on semaphore foobar
Feb 13 13:15:07 'thread2'[201]: Waiting on semaphore foobar
Currently, all messages are logged in a single system-wide
file. Ideally, I'd like to set up the ability for each
application to optionally specify a different log file, but
it's unlikely that I'll have that finished for DR9. I'm also
planning a reasonably nice Log Viewer (a la Event Viewer on
Windows NT), which will allow users to view and sort
messages according to various criteria.
This, along with the debug_server enhancements and fixes
that are also going to be in DR9, should make both styles of
debugging in the BeOS a whole lot more pleasant. If you'd
like to offer further ideas as to what would make your life
easier, please don't hesitate to send me e-mail at
mani@be.com.
BE ENGINEERING INSIGHTS: The Media Kit
By Marc Ferguson
The Media Kit provides direct access to the buffers used by
the built-in analog-to-digital converter (ADC) and digital-
to-analog converter (DAC) on both BeBox(TM) and Macintosh
computers. Because the audio hardware is shared between
applications, the audio data format of the buffers must be
the same for all applications that are using the hardware at
one time. Here are some suggestions for applications that
want to play well together.
We strongly recommend that you run the ADC and DAC streams
in 16-bit stereo mode. Fortunately, it's easy to convert
between 8-bit and 16-bit and between mono and stereo
formats. 16-bit stereo is the only format supported by the
standard Macintosh hardware.
We also recommend that, if possible, applications support a
sampling rate of 44.1 KHz. If it's necessary to do
processing at 22 KHz, then 44 KHz input can be downsampled
to 22 KHz by taking every other sample, and 22 KHz can be
converted to 44 KHz by filtering or interpolation. Linear
interpolation may be sufficient.
To lead the way in following this advice, I dusted off an
old application I sometimes use to test the audio streams.
The Laserbreath application is a linear-phase bandsplitter
with an adjustable time delay applied to each band. My 66
MHz BeBox isn't fast enough to process many bands at 44 KHz
stereo, so I modified the program to do its processing at 22
KHz and to use linear interpolation to output at 44 KHz. The
application with source code will be posted as sample code
on the Be ftp site (ftp.be.com).
The Laserbreath application uses a Nino object (described in
Be Newsletter #36) to connect the ADC stream to the DAC
stream and does it's processing in the DAC stream. To use
it, feed an audio source into the ADC, mute the loopback
control, and listen to the DAC output.
There are two rows of (very simple) sliders. The top row
controls the level of each band, like a graphic equalizer;
the bottom row controls a time delay for each band. The
bands are equally spaced, having higher resolution at high
frequencies and lower resolution at low frequencies than a
typical graphic equalizer, whose bands are octave spaced.
This type of bandsplitter is more applicable to noise
reduction than to equalization. The name Laserbreath
probably comes from the swooshing sound produced by the
default setting for the delays.
The bandsplitting algorithm used is quite elegant and is
described in and article by J. A. Moorer and M. Berger,
"Linear-Phase Bandsplitting" (J. Audio Eng. Soc., Vol. 34,
No. 3). The input is fed into a comb filter, so called
because its frequency response curve looks like a comb, with
many sharp zeros of transmission. If the input samples are
X[n], then the comb filter output is C[n] = X[n] - X[n - P],
where P = (2*nB - 2) and nB is the number of bands to be
split. The zeros of transmission of the comb filter occur at
wavelength which evenly divide P samples which correspond to
frequencies which are multiples of Fs/P where Fs is the
sampling rate. The output of the comb filter is sent to a
parallel bank of resonators (implemented as second-order
recursive filters). Each resonator has a resonant frequency
corresponding to one of the zeros of transmission of the
comb filter, and its output passband is centered around that
frequency.
The outputs of the bandsplitter are the same as you would
get if you computed an FFT for each input sample. Because
the input to each successive FFT differs only by adding one
sample at one end and removing one sample at the other, the
computation can be reduced to the recursive form used here.
News from the Front
By William Adams
So for once I'm not going to be long-winded.
Most of the time when I hear my daughter speak, I can
understand what she's trying to convey. Whenever someone
else listens, they don't necessarily get the message,
because a 21-month old doesn't really have a firm grasp of
the language yet. Her message is garbled, but we go over it
again and again until her words are crystal clear and we're
communicating.
There's quite a lot going on with Be right now, and you
should be hearing good news about various licensing
agreements, marketing plans, distribution opportunities, and
the like. We'll try to make our plans crystal clear, and you
shouldn't have to strain to get our message. So I'll say it
again here for reference: For this year, our plan is to get
apps out there on a stable OS that will be very prolific.
To this end, we want to support our developers as much as
possible in getting up on the current release as well as
getting to DR9 as quickly as possible. Applications written
for DR8 will not be binary-compatible with the DR9 release,
thus developers will have to recompile their code and make
some modifications in order to take advantage of new
functionality.
Needless to say, we want as many apps available on DR9 as
soon as possible. We have mentioned a couple of times our
desire to host a porting lab. Thus far the response has been
positive. Now, we'll get more formal about it. If you want
to participate in a porting lab, then please send a message
to devservices@be.com. The lab will be held in mid to late
March, and as the date approaches, we'll get more specific.
But since we expect this space to be limited and in high
demand, you'll want to at least sign up now.
This lab is intended for developers who intend to ship a
product that is for purchase with DR9 and for whom timing is
critical. If you have a product that's for your own use and
don't mind waiting a few weeks, then you shouldn't come to
this lab. The lab will be on-site here at Be and will be
available for a two week period.
Another near-term event is the Developer's Conference, which
will be held around the same time as the World Wide Apple
Developer's Conference. May 10 and 11 are the tentative
dates here in the Santa Clara Valley. We'll be presenting a
number of topics primarily related to getting to DR9 and the
future of the BeOS. A two-day event is scheduled with an
emphasis on getting your code working. We're planning a
number of introductory and advanced sessions in which there
is some lecture and discussion, and we'll make available a
number of machines for developers to actually write code on.
We want this to be a very interactive, participatory event,
so we won't try to usurp your time. We also want developers
to be involved personally, so we'd like to hear from you as
to any particular topics you want covered. We already have
an agenda that covers most of what DR9 is going to be, but
we'd like to take topics from you as well. We'd also like to
give you the opportunity to give a presentation yourself if
you have expertise in a particular area. If you think you'd
like to give a presentation at the conference, please send
e-mail to hopwood@be.com. Michael Hopwood is our Product
Manager and Evangelist and is coordinating this conference.
He'd love to hear from you.
This week finds us in both Tokyo and Paris. Big
announcements, lots of demos, lots of code being written.
The BeOS is a fun place to be, and looking more lucrative
every day. You'll see reports on both of these events over
the coming weeks.
So like I said, GCC has been ported to the BeOS by Fred
Fish. This guy is totally amazing and has done a ton of work
in getting standard GNU utilities supported on our platform.
To begin rewarding his efforts, we're going to include a lot
of his work into the DR9 release. GCC in particular was used
to compile a number of the utilities. Don't start asking
questions about whether this means we support Objective-C
and whether you can use g++ with Metrowerks code. The answer
is, you can use gcc to compile the GNU non-UI, non-C++
utilities, and that's about all we're going to support. We
won't include the gcc compiler as part of the system, since
it would just cause confusion as to which tools are truly
supported, but it will be darn easy to get it and install
it.
Along the same lines of incorporating developer code, we're
also including the DataTypes library from Jon Watte of
Metrowerks. As mentioned oh so many moons ago, this library
allows for the easy translation of datatypes in any
application, without the developer writing specific code for
all data types. Our very own Hiroshi Lockheimer has
incorporated Styled Text into DR9 as well. So, that's the
way things go. Developers work their hearts out to promote
an OS, and they're rewarded with positive and appreciative
responses from the OS vendor. Isn't that the way it works
with all OS companies?
If I can't write next week's article within the next 12
hours, then you'll get a break from me for a week, so until
then, get back to coding so we can show off your stuff!
Boardwatch
By Jean-Louis Gassée
This is a magazine I highly recommend to anyone interested
in the Net and to anyone who's tired of the bland and
predictable prose you'll find in magazines published by
corporate giants. A little history will explain, perhaps,
why I like and recommend -- two distinct notions -- this
monthly publication.
When we started Be, one of our key goals was to link our
customers, our developers, and ourselves in one community.
This was in early 1991, when we were writing the first Be
business plan. We wanted customers to register on-line, so
they would receive weekly e-mail notifications of bad news
(more bugs found) and good news (more applications
available). We also wanted customers to tell us swiftly what
they hated and, perhaps, what they liked. Just as important,
we wanted developers to market and deliver their software
on-line, promoting their wares on our bulletin board,
offering demos as well as full versions, bug fixes, new
releases, helper apps, the works.
I wrote "bulletin boards." They were the rage at the time.
There was a very large community of bulletin board systems
developers and users. Some ran on Macs, with an
exceptionally good one deservedly called FirstClass. Most
worked on cheap (I mean inexpensive) PCs, with software from
companies such as Galacticomm, eSoft, or Mustang, with geeky
multiport boards and networks to string the PCs together if
you scored more subscribers. At the time, companies such as
MacAfee were doing a brisk business selling anti-virus
software with such systems, roomfuls of PCs on Novell
networks. From the two or three BBS magazines in existence
at the time, one was clearly the leader, Boardwatch, and it
organized a convention, BBSCon. So we went there (it was
held in Colorado Springs in '92) to check companies and
products. Quite a scene if you'd lived too long in the Apple
cultural framework; an exciting one if you were looking for
action. The famous Star Wars bar scene came to mind with all
sorts of mutants speaking in tongues and big beer bellies
stretching t-shirts reading "Windows is for sissies." Geek
heaven.
So I kept reading Boardwatch, I subscribed, got on their own
BBS from my Windows machine, and logged onto the many
FirstClass systems worldwide from my Mac. We even thought it
would be exciting to bundle a Be version of FirstClass with
each system we'd sell, your own personal server. This was
before the Internet came out of UNIXdom.
My liking and respect for Boardwatch grew even stronger when
I saw the magazine take to the Internet and the Web. Jack
Rickard, the editor, reacted sooner and faster than Bill
Gates. Today, it's the Internet magazine to read if you want
information and opinion unmitigated by corporate minions and
focus groups. Jack Rickard writes what he wants, answers
reader mail any way he wants, and the result is informative
and liberating. I have yet to read someone who understands
the technology and the games being played as well as he
does. Eons before anyone in the trade, Boardwatch had great
HTML tutorials, and when Windows 95 came out, it was the
only source of non-PR information on Win95 networking. Great
discussions of legal issues as well, more competent than in
the general computer press, politically on the "leave us
alone" side of the aisle and honest about it.
http://www.boardwatch.com, jack.rickard@boardwatch.com.
Enjoy!
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- -----WEEK 4---------------------------
Subject: More GUI questions
Modal window talk. Loren Wilton divided the modal dialog
world into three continents: System, application, and
window. All three are bad, opined Mr. Wilton, but the first
two "should be avoided like the plague..."
Also, what buttons should appear in a dialog? There were
some specific, button-by-button suggestions, as well as a
higher-level buttons-vs-pop-up debate. What about bucky
clicks (modifier-key-plus-mouse-click)? Should they be
avoided? Allowed for "super-users?" How about if the button
labels change when a key is held down?
- -----NEW---------------------------
Subject: Multi-user?
A seemingly simple question from Ficus Kirkpatrick: Will the
DR9 file system support multiple users?
As listeners wrote in to give evidence of the necessity of
multi-userness, it became clear that the question wasn't so
simple. Although most folks take "multi-user" to mean,
primarily, security, it can also mean preferences,
distributed data, and so on. This prompted a suggestion from
Jake Hamby:
"HEY BE, why don't you implement a simple single-machine
security model, but provide hooks for us third parties to
add in NIS, DCE, or whatever support later on?"
After the initial gotta-have-it frenzy, it was conceded that
there may be more important things that Be gotta have.
THE BE LINE: DR9 will have limited multi-user support: The
file system will record ownership, group, and permissions,
but it may not actually apply them. Don't look for user
passwords in DR9.
- -----NEW---------------------------
Subject: Messages for device drivers?
Should Be provide high-level communication with drivers? For
example, what if a driver needs (or wants) to prompt the
user for information -- can it pop up a window? How about
the case where a driver needs initialization info -- is
there any guarantee that a "run me first" config file will
actually get loaded before some other program tries to use
the driver?
It was suggested that NT has a particularly elegant solution
to the driver configuration problem. Also, Mac's
Notification Manager was cited as a good example to follow.
- -----NEW---------------------------
Subject: dr9 FS Thought
Is it possible and desirable to have an "app as directory"
structure (a la NEXTSTEP and others). This would allow extra
info (icons, sounds, fat binaries, and so on) to be packaged
with the app but still live in distinct files. The
"directory-ness" of the app would be hidden from the
(common) user: Within the Tracker, the app directory would
look like an app icon that you can double-click to launch.
Resources were suggested as a more acceptable means for
bundling app info into a packagable entity (that is, a
file). Pro: Transferring a file is easy. Con: Huge amounts
of read-only data (documentation, for example) is easier to
handle if it's packaged in separate files.
Extrapolating from the DR9 FS info that's been publicized by
Be, one listener suggested that attributes may be better
than resources for storing app-related info. In fact, why
not scrub resources altogether? Can't the attribute system
be used as a replacement? It was quickly pointed out that
resources and attributes are different: Resources are stored
in the file (better, they "are" the file) and attributes
aren't.
- -----NEW---------------------------
Subject: WinCast TV Card
Folks are thrilled by the quality of the live video they get
with the WinCast card connected to Be's bt848 driver. For
info on WinCast, see
http://www.hauppauge.com/hcw/html/wc_data.htm
So, Be, how about real support for the driver?
THE BE LINE: DR9 will include an elegant interface to live
video drivers.
|
