[nas] another patch for auplay

[Jon Trulson]

On Mon, 29 Jan 2001, Paul Fox wrote:

> Date: Mon, 29 Jan 2001 12:13:36 -0500
> From: Paul Fox <pgf at foxharp.boston.ma.us>
> To: nas at radscan.com
> Subject: Re: [nas] another patch for auplay 
> 
>  > > 
>  > > these patches were driven by my home voice-response menuing system. 
>  > 
>  > 	Sounds interesting... what do you use for voice recognition?  
> 
> ah, sorry.  didn't mean to mislead.  the input is via IR remote, using
> the lirc package, and a couple of random remote controllers.
> 

	Ahhh... bummer ;-)

>  > > the other option, "-s", didn't go in quite as cleanly, i'm afraid, but
>  > > i found it was equally important in my application.  in order for new
>  > 
>  > 	This one does too, but will be a little tricky... IMHO, I think
>  > auplay should always stop the flow immediately when it's interrupted.  
>  > The issue now is how to amend the API in such a way that you can get
>  > access to the flowid from AuSoundPlaySynchronousFromFile() (and it's
>  > asynchronous cousin.)
> 
> yes, that was my problem.  :-)
> 
>  >   Or perhaps auplay should just be enhanced to always
>  > use it's own playFile routine using low-level calls.  This would also make
>  > it easier to add another often requested feature - the ability to detect
>  > and play audio from stdin...  Thoughts?
> 
> doesn't it do this now?  the code certainly tries -- if there are no
> filename args, it tries to play the file called "-".  i assumed the next
> lower level did the right thing, but i didn't actually go and look.  :-)
> 

	Well, it tries to do this now, but it will only succeed if the
input data happens to be .au format.  Otherwise it will fail...


> btw, as i was putting together that patch, i noticed that the signal
> handler should probably, as is done when falling out of main(), call
> AuCloseServer() before calling exit.  but doing that broke my setup
> badly, and i'm not quite sure why.  somehow actually telling the server
> that you're "going away" causes something to misbehave in a way that's
> different than if the client simply drops its end of the connection.  i
> confess i didn't investigate as well as i should have.
> 

	What kind of misbehavior did you see?  

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
Free Mars!