[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nas
Subject:    Re: Some things I noticed ...
From:       nowhere!sking () geraldo ! cc ! utexas ! edu (Steven King)
Date:       1994-07-05 8:33:41
[Download RAW message or body]

> 
> Yep.  This works like the X Window System.  According to _X Window
> System_ (Third Edition by Scheifler & Gettys):
> 
> 	"Every core event ... also contains the least-significant 16
> 	 bits of the sequence number of the last request issued by the
> 	 client that was (or is currently being) processed by the
> 	 server."

  Oh wow!  How embarassing, after 4 years of messing with X, I never realized
 that (I was thinking it was the serial number of the event).  And its there
 in the X man pages if one pays attention.  Sigh.  I'll have to cleanup the
 entries for events...

> I'm not opposed to adding such a macro.  Has anyone actually used the
> children information?

  I was thinking it could eventually be usefull.  If I understand the intent
 behind child devices correctly, they are for devices that share the same
 physical hardware, ie, the stereo servers all define a mono output subdevice
 whose output gets merged with the stereo output.  However, if one had an
 independent physical device (ie, if my sbpro and pas16 will tolerate each
 other, I should have three independent half-duplex devices, one 8 bit mono,
 one 8 bit stereo, one 16 bit stereo, each with their own sample rate and
 thus operating asynchronously to the others) one could have both a mono
 output subdevice to the stereo device and a mono output non-subdevice.  If
 a client, for some reason wanted to distinguish between the two, it would
 need to use the children information.

> The trivial flow stuff is a gross hack.  The goal of trivial flows was
> to be able to fill a bucket with a minumum of overhead.  That was also
> one the goals of unclocked flows.  I think what I really want is a
> trivial unclocked flow :-).  If you look at the code that loads up
> buckets in soundlib.c you'll see that the flows that are used are
> unclocked.  This is certainly an area that needs some cleanup.

  I think the test for trivial flows needs to check if the flow is unclocked,
 the sample rates and the format are the same, and num_samples in the bucket
 is 0 (that or respect the num_samples value).  I suppose the test will end
 up being the least trivial part of the flow...

> See the above comments about trivial flows.  The idea behind unclocked
> flows was to have the data moving within the flow as fast as the
> server could go, rather than at some set rate.  We intended unclocked
> flows to be used primarily to read and write buckets.  But then we
> decided that even an unclocked flow would have too much overhead for
> simple bucket operations.  Hence trivial flows.
> 

  I was thinking that its probably unneccessary for the programmer to
 distinguish between clocked and unclocked flows; if a flow imports or
 exports to a device (or radio) it should be clocked, and if it doesnt, it
 shouldnt.


-------------------------------------------------------------------------------
take your pick                         sking@nowhere
                                       nowhere!sking@geraldo.cc.utexas.edu
                                       ...!cs.utexas.edu!geraldo!nowhere!sking

"its not the heat, its the stupidity"

[prev in list] [next in list] [prev in thread] [next in thread]