Subject: Faces audio support - comments please.

From: richb@stard (Rich Burridge)
Date: Thu, 4 Apr 1991 08:07:37 +1000

I'm going to try to add audio support to faces for patch #15. Before I do,
I'd like to throw my ideas at the list, and get a discussion going. I know
that John has some ideas on this. My perspective is also biased towards Sun
gear, so my ideas might not be as general as they should be.

* There will be a default command for playing audio files.

* There will be an additional two entries in the Makefile.dist file for
  specifying whether the program is capable of supporting audio, and an
  option audio play command (to override the default one):

  #AUDIO_SUPPORT	= -DAUDIO_SUPPORT
  #AUDIO_CMD		= -DAUDIO_CMD=\"/usr/local/bin/play\"

* There will be a new command line option:

  -A [play command]

  -A on it's own enables audio support. It's disabled by default.

  -A [play command] allows the user to supply an alternative command to
     obey, to "play" the audio file.

* There will be two new X resources:

  faces.audioSupport:	true                     [default is false].
  faces.audioCmd:	/usr/local/bin/play

* The XView property sheet will have another check box:

  [ ] Audio support

* Whether an audio file should be played is determined by the presence of a
  face.au file in the host/user directory. I suspect that due to the size of
  most audio files, these will really be symbolic links to a large audio
  file directory somewhere.

* Because faces currently checks so many different directory and name
  combinations, I suggest that it should only look for the face.au file
  when an equivalent face.xbm/48x48x1/sun.icon/face.ps file has already
  been found. In other words, there shouldn't be host/user directories
  with just a face.au file in them, because with this suggested lookup
  technique, they simply wouldn't be found.

  I suspect this point will be a hot topic for discussion. I'm flexible,
  but faces is really slow at the moment on large mail files.

* When a face.au file has been found for a host/user (could be misc./unknown)
  then if audio support is enabled, the system() library call is used to
  play the sound. I considered forking a process, but it's possible that
  there could be a lot of host/user's that will have audio files associated
  with them, and you could end up with a couple of dozen sub-processes going.
  Combine that with the fact that only one process can have the Sun audio
  port open at any one time, I really wasn't left with too much choice.

So there are my suggestions. This is surprisingly simple to implement, and
hopefully would be a stiff competitor for those new xbiff++ programs that
are starting to emerge on the net.

Comments please.

---

From: John Mackin <[email-masked]>
Date: Thu, 4 Apr 91 10:17:16 +1000

Argh!  Rich, I'll have to exclude your middle if you keep this up :-).
How can I catch up with the huge backlog of stuff I need to do for you
_and_ take part in current-time discussions on the list at the same time?
(That's rhetorical and I am choosing the second.)

    From: [email-masked] (Rich Burridge)
    Date: Thu, 4 Apr 1991 08:07:37 +1000

    I'm going to try to add audio support to faces for patch #15.
    Before I do, I'd like to throw my ideas at the list, and get a
    discussion going. I know that John has some ideas on this. My
    perspective is also biased towards Sun gear, so my ideas might not
    be as general as they should be.

I do indeed have ideas.  I won't quote Rich's mail at length here;
see the referenced message.  I do want to stress that I too am most
interested in hearing from people with non-Sun audio support, since
I, like Rich, have Sun hardware.  (There does seem to be a pretty reasonable
de-facto standard for telephone-quality audio data, though, namely 8 bits
inverted signed x 8000 per second; happily, you can cat that at /dev/audio
on a Sparc and it works.  Other systems don't support the same sound
file header format that the Sparc software does (and that some file(1)
commands recognise -- file begins with ".snd"), so we probably shouldn't
tie ourselves to that (not that anything Rich suggested meant that we
were doing so).)

Now about Rich's suggested implementation.  It's much more ambitious
that what I had in mind.  I was just going to add a command which would
be system()'ed instead of ringing the bell, if it was present.  So, there
would just be one "There is new mail" sound, not a sound per face.
(This could also be accomplished at the protocol level, by using the Xsun
contributed audio-bell mods, but that means you get the same sound when
any application rings the bell.  That's all very well, but my goal here was
a distinguished sound just for mail arrival.  And of course, that assumes
not only that you are using X, but that you can hack your server; neither
assumption is true for the whole faces user community, by a wide margin.)

Unfortunately, Rich's suggested implementation does not allow what I want,
unless you are prepared to go to the overhead of a face.au symlink in
_every_ leaf directory of the tree; in most instances, to the default
sound, otherwise to the particular sound.  This is quite ridiculous,
and is really the only quarrel I have with the suggestion's design.
There should be an optional resource "audioDefaultFile" or similar,
and parallel .facesrc options, command line options, etc.  If the file
is specified and no .au file is found in the leaf where the face is,
then that file is played the same way a .au file in the leaf would have
been.

I also have some general comments about X resources vs property sheets vs
command line arguments vs .facesrc etc ad inf, but I will hold them for
a later message in the interests of getting this one out.

I do have one problem with the detail, as opposed to the concept, of
Rich's suggestion:

This is in contravention of the SVID.  Those of you that know me either
know what's coming or are shocked, since I would never advocate that anyone
follow the SVID; but in this specific instance, its English is _so_ beautiful
that it can't be resisted, to wit:

	Option arguments cannot be optional.

(SVID aside, it's bad user interface design anyway.)  What that lovely
sentence means is that if you have an option, say -A, then it either
always takes a following argument, or it never takes one.  If you're
using getopt or similar to parse your arguments, you must do it like this
anyway.  It also means that the user doesn't have to worry about whether
there should be whitespace between the option and the argument.

So, concretely, I suggest: -A enables audio support, disabled by default;
-P <command> turns on -A and sets the play command to the one given.
I don't care what the names really are, all I care about is that `option
arguments cannot be optional'.

More later,

John.