Re: being serious about the NG of zinf

Tim Lesher wrote:
> On Wed, Apr 30, 2003 at 09:01:24PM -0400, Ed Sweetman wrote:
> 
>>Right now I'm opposed to using threads for the main player.
> 
> 
> That's a good start.  There's rarely a problem that can be solved with
> threads that can't be solved more simply and reliably with other
> means.
> 
> While the pipeline probably doesn't need to be threaded, we might want
> to allow the UI to exist on another thread, and then put all the
> UI/pipeline interactions in a very tight interface.
> 
> 
>>In other areas of design, ideas such as the mapped strings for managing 
>>preferences are going to be put into use.  [...]
> 
> 
> Great.  I was thinking about something very similar.  The preferences
> coupling should be as loose as possible.

preferences and the playlist are just mapped strings.  plain and simple. 
  Of course like the preferences, the player isn't going to talk to the 
mapped string directly.  The preferences are wrapped in the info class 
and accessed by methods in it.  The playlist will be accessed by a 
playlist class that gives complete functionality that you've come to 
expect from the gtk ui and more.  I'd like to offload functionality from 
the UI's and allow the ui subsystem to be just that, the user interface 
and not part of the "program."


> 
>>changing in the meantime, we need a boolean member to info called lock. 
> 
> 
> Checking a variable doesn't prevent race conditions at all because
> threads can be switched after checking the condition, but before
> reading the data.
> 
> We'll either need to use a real synchronization object, or else
> stipulate that plugins can only read the info object from the main
> (creation) thread.

We could use rwlock directly and screw the whole c++'ifying it. That 
should prevent any sort of problems stemming from the locking class and 
give the info object the best behavior.  info would contain the lock and 
every method at the beginning would start the appropriate lock and close 
it at the end at first. Later on we could decrease the scope of the lock 
to only the data that isn't on the stack.

> 
>>I do 
>>still have my doubts on how feasible it will be to not depend on libs 
>>for certain protocols in the input plugins so this is still
>>debatable.
> 
> 
> I think you'll find that we'll still want to use libs for input
> plugins.

for certain protocols i can see that, yes.

> Sounds like a good initial vision.
> 

for cd input i'm pondering two modes.  Analog and  digital.  Analog 
would have to have a null decoder plugin and we can have the init of the 
output plugin check to see if our decoder is gonna be NULL and decide 
we're playing a CD and if cooperative volume is not enabled, to make the 
volume controls on the player point not to the pcm audio but to the cd 
volume mixers.  Digital of course would probably use cdparanoia's lib 
and a cd decoder that would simply make any byte position adjustments 
needed per arch and send it on it's way to the output plugin like normal.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf