home *** CD-ROM | disk | FTP | other *** search
/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / MM1 / TELECOM / linkup12.lzh / DOC / audioplay.doc < prev    next >
Text File  |  1996-04-08  |  5KB  |  117 lines
  1.                           AudioPlay (edition 4)
  2.               by Boisy G. Pitre/Andrzej Kotanski/Mike Haaland
  3.  
  4.  
  5.     AudioPlay is a program which plays .au, .wav, .voc and .iff sound
  6. files.  It is based on code that was made available to the public domain
  7. by Andrzej Kotanski (kotanski@zeus02.desy.de) and contains several
  8. features which make it a fairly robust audio player for the MM/1.
  9.  
  10.  
  11. How does AudioPlay work?
  12. ------------------------
  13.     AudioPlay reads chunks of data from the sound file it is playing
  14. and keeps two buffers.  One buffer is the currently playing buffer
  15. and the other buffer is the next one to be played.  AudioPlay takes
  16. advantage of the MM/1's DMA driven sound.  While one buffer is playing,
  17. AudioPlay reads the next sound chunk into alternate buffer and goes to
  18. sleep waiting for the previous chunk to finish.  This process continues
  19. until all chunks of the sound file have been played.
  20.  
  21.     The result of this dual buffer scheme is that a machine with limited
  22. memory can play a sound file continuously without having to resort to
  23. loading the entire file into memory.
  24.  
  25.     The following paragraph is from Andrzej Kotanski:
  26.  
  27.     "All files are played in stereo - the mono files are converted to stereo
  28. by sending identical sounds to both channels. Although MM/1 has an
  29. (undocumented) mono mode, it sends bytes to alternate channels. This causes
  30. audible distortions of the sound (unless both channels are connected to the
  31. same speaker)."
  32.  
  33.     AudioPlay looks at the sound file being played to determine what type
  34. it is.  Therefore the filename or extension is not used to determine its
  35. type.
  36.  
  37. What are the options available?
  38. -------------------------------
  39.     Doing an audioplay -? at the shell prompt gives you:
  40.  
  41.     Syntax: AudioPlay {[<opts>] [file] [...]}
  42.     Function: plays .AU, .WAV, .VOC and .IFF sound files
  43.     Options:
  44.          -b[=]<size>   buffer size (in K-bytes)
  45.          -p[=]<pid>    process to send <sig> to when done
  46.          -q            quiet mode (no output)
  47.          -s[=]<sig>    signal to send to <pid> when done
  48.          -f            force event
  49.  
  50.     More than one filename can be placed on the command line.  Each will
  51. file will be played consecutively.
  52.  
  53.     An explanation of each option follows:
  54.  
  55.              -b[=]size     buffer size (in K-bytes)
  56.  
  57.     -b allows you to specify the size of the buffer that AudioPlay can
  58. use to play sound files.  The default size is 100K and the minimum buffersize
  59. is 10K.  This is the size of one of the buffers that are allocated, so
  60. at a minimum, size times 2 bytes of memory will be allocated (if the file is
  61. a mono file, size times 4 bytes are allocated).
  62.  
  63.     Users with fast hard drives shouldn't need to adjust the 100K default
  64. buffer size.  Users playing sound files from floppy drives and other slow
  65. devices may need to increase the buffer size to prevent lapses between
  66. playing chunks of audio.
  67.  
  68.  
  69.              -p[=]<pid>    process to send <sig> to when done
  70.              -s[=]<sig>    signal to send to <pid> when done
  71.  
  72.     AudioPlay can send a signal to a process when it has finished
  73. playing a sound file.  This is especially useful for processes which
  74. fork AudioPlay as a child, but who do not want to wait for the audio
  75. file to complete before continuing execution.  By passing the process
  76. ID and a signal code, AudioPlay notifies a process that it is about
  77. to exit.  If the process receiving the signal is the parent of
  78. AudioPlay, it can properly wait for its child to die.
  79.  
  80.  
  81.              -q            quiet mode (no output)
  82.  
  83.     By default, AudioPlay prints out verbose information to the
  84. screen indicating the name of the file, any annotations, the sample
  85. rate, the size of the file in bytes and how many channels it is
  86. using.  This option inhibits AudioPlay from printing any information
  87. and is useful when being forked from another process.
  88.  
  89.  
  90. Miscellaneous Notes
  91. -------------------
  92.     AudioPlay was compiled using Microware's Ultra C compiler.
  93.  
  94.     AudioPlay creates and uses an event called 'mm1_sound' to prevent
  95. another AudioPlay process from trying to play a sound file at the same
  96. time.  If two or more AudioPlay processes are forked simultaneously,
  97. only one will execute at a time.  The others will wait on the event.
  98. Because of this, you should never send signal 0 (the unconditional
  99. kill signal) to an AudioPlay process, or it will not properly reset
  100. the event so that other AudioPlay processes can function.
  101.  
  102.     If by some chance the event does get 'hung', by AudioPlay aborting
  103. abruptly, the -f option will reset the event.  The only other recourse
  104. would be to reboot the machine.  This option should only be used if your
  105. sure the event is locked and no other process is using it.
  106.  
  107.  
  108. Boisy G. Pitre
  109. Internet  : boisy@os9er.waukee.ia.us
  110. Delphi    : BOISY
  111.  
  112. Mike Haaland
  113. Internet  : mhaaland@hypertech.com
  114. Compuserve: 72300,1433
  115.  
  116.  
  117.