Re: cvs cd problem

I've applied your patch by hand.  I left out the 
the ".so" changes for the moment as I think this will
also impact win32 and we should let Tim get on with his
work before trying some new stuff.


On Fri, 2003-03-21 at 13:25, Ed Sweetman wrote:
> Ed Sweetman wrote:
> > Kristian G. Kvilekval wrote:
> > 
> >> On Thu, 2003-03-20 at 18:06, Ed Sweetman wrote:
> >>
> >>> Our default is set to soundcard-pmo.so which is not built apparently. 
> >>> ALSA is built. so for people who dont have soundcard-pmo.so our 
> >>> player defaults to the first pmo in the list, which happens to be the 
> >>> cd pmo for most people.  The player does not make any intelligent 
> >>> decisions on which pmo to use at this point.  So it uses the cd pmo 
> >>> to try and play any file.
> >>
> >>
> >>
> >> How about changing the preference to a list of pmo to try in order
> >> instead of just skipping over the ones.   i.e. try alsa, soundcard,
> >> esound, arts...
> > 
> > 
> > did you look at the patch?  It tries the first non-cd and non-waveout 
> > one. There is no need to try and get soundcard/alsa/esound/arts in a 
> > particular order when the one that's selected in the preference file 
> > isn't found.  The method i'm using works the way zinf is supposed to 
> > work in this situation.   The way it was prior was bad.
> 
> In case you're missing it.
> 
> 
> 
> +	   if(!item){
> +		cerr << "Requested pmo " << defaultPMO.c_str() << " not found\n";
> +		int32_t xx = 1;
> +		item = m_pmoRegistry->GetItem(0);
> +		while(!strcmp(item->Name(), "cd-pmo.so") ||
> +		      !strcmp(item->Name(), "wavout-pmo.so")){
> +		    item = m_pmoRegistry->GetItem(xx);
> +		    xx++;
> +		}
> +		cerr << "using pmo "<< item->Name() << " instead. Update pref\n";
> +	    }
> 
> 
> 
> what this says is if we dont have a output plugin because the default 
> wasn't found in the list of plugins we have available to use as output 
> plugins then we output that the requested plugin wasn't found. We 
> initialize our counter to one and preload item to the 0 position of the 
> registry we compare this to "cd-pmo.so" and "waveout-pmo.so" because we 
> dont want to use them as backup audio output plugins ever. If it's 
> either one of those we set item to the next item in the registry and 
> incriment our counter and try again.  It exits this loop when we find a 
> plugin that is not the cd-pmo plugin and  not the waveout plugin. We 
> output which plugin we're using and tell them to update their 
> preferences and continue on our merry way.  If none is found zinf will 
> exit with an error like you'd expect it to if you had no pmo plugins.
> 
> The way it worked before was that it used the 0 position plugin and went 
> on it's merry way and that's it.  It didn't care if it was the cd plugin 
> or the waveout plugin or what.  This is bad and lazy.
> 
> The fix above is a perfect solution with the exception that it doesn't 
> attempt to decide if you have the audio drivers loaded for the 
> particular output plugin it's attempting to use. But that is well beyond 
> the scope of zinf.  There is no better way to decide which plugin to use 
> in the absense of the one we want.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Zinf-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/zinf-devel
-- 
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en