[nas] mpg123 on NAS questions

[Jon Trulson]

On Wed, 9 Jan 2002, Paul Fox wrote:

> Date: Wed, 09 Jan 2002 09:20:03 -0500
> From: Paul Fox <pgf at foxharp.boston.ma.us>
> To: nas at radscan.com
> Cc: mh at mpg123.de
> Subject: [nas] mpg123 on NAS questions
> 
>  
[...]

> sending this mail, but don't see anything there that would
> affect either of these problems.)
> 
> problem 1 -- when i try and use mpg123 with irmp3 as a
>     front-end control program, it seems that mpg123 reports
>     that a song has finished playing a bit prematurely. 
>     what happens is that mpg123 finishes sending data to
>     NAS, reports that its finished to its front end
>     controller, and irmp3 either kills it off or starts the
>     next song, but in either case this breaks the mpg123
>     connection to NAS, and the end of the song is truncated.
>     
>     when mpg123 is exiting, it waits correctly for the data
>     to finish playing -- so i guess the call to AuCloseServer
>     in that case is causing the right thing to happen.  i
>     was able to fix the early truncation problem by
>     inserting calls to audio_reset_parameters() just before
>     each instance of sending a "generic_sendmsg("P 0");"
>     report.  this causes the audio connection to be closed
>     and reopened after every song, which seems like
>     overkill.  but i tried just doing an AuSync() and
>     AuFlush() at that point and that didn't do the trick.
>     what's the right NAS call to ensure output has been
>     written to the device?  (i can't quite tell from the man
>     pages whether i'd want AuSync or AuFlush.)  surely there's
>     a way to wait for the server to drain?
>     
>     oddly, when i added the close/reopen (via audio_reset_paramters())
>     i also found that i had to add an AuSync/AuFlush pair to
>     the audio_close routine to make it all work right. 
>     clearly i'm a little confused about how this should all work.
> 

	Strange.  I'm not familiar with the mpg123 nas implementation, so
I'm not really sure what is up... I've only used it to play one source at
a time and I mainly use xmms now... The AuSync/AuFlush only deal with
ensuring that the currently buffered data by the app (libaudio) is sent to
the server or discarded depending on what you use and the args you pass
it.  They don't really effect the server in it's transmisison of data to
the actual device.  It seems to me (without actually trying it of course
;-) that you would want to loop accepting events until a AuStateStop
arrives, which should happen when all the data has been played.

	I don't know how irmp3 controls mpg123, but the problem may be
there... Ie, the data is not getting a chance to flush, and events are no
longer being processed...
	

[...]
> 
> 
> problem 2 -- when mpg123 is "paused", via its control
>     interface, it stops sending data immediately, but of
>     course there's quite a bit of sound buffered in NAS at
>     that point, and it can take many seconds for the pause
>     to take effect.  is there a NAS "suspend" api that could
>     be invoked somehow at that point to stop the flow
>     immediately?  the same problem is noticed is one simply
>     sends mpg123 a STOP signal -- sounds keeps coming out
>     for quite a long time.
> 

	You indicated before that there was a lot of data buffered... How
many seconds does it keep playing?  I think the default is 5
seconds.  I know you can stop the flow with AuStopFlow() (or
perhaps AuPauseFlow() is more appropriate in this case?).  auplay's
sighandler does this to respond appropriately to INTR...  Then you should
be able to do a AuStartFlow() to resume.


-- 
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>
Bad Color Temperature, Too much Peach.