Re: patch to esound to use ARts (KDE sound subsystem) if it's running

[Vlad Harchev <hvv hippo ru>]

On Mon, 27 May 2002, Yo Ric Dude wrote:

 In short - all of your comments except the last are obsolete since you seem
to be commenting on the obsolete version of the patch. The latest version of
the patch is attached to that ticket since previous Thursday or so. Your
comments on the latest version of the patch are greatly appreciated.

> > 1.  audio_aix is (was?) actually audio code for the AIX variant of UNIX.
> The arts specific code should go into audio_arts.c, or perhaps more 
> appropriately, audio_arts_fwd.c, as it forwards audio info to arts.
> 
> 2. combine move dlarts() into arts_init()
> 
> 3. use function pointers to evaluate the right esd_audio_*() functions.
> e.g. have a variable: use_arts = 0 or 1, depending on the initialization of
> the arts subsystem.  have a function pointer vector, arts_audio_write_vec[2],
> whose first element is esd_audio_write(), and whose second is 
> arts_do_audio_write().  All the ugly #ifdef logic in audio.c abbreviates to:
> 
> int arts_audio_write( void *buffer, int buf_size )
> {
>      return arts_audio_write_vec[ use_arts ]( buffer, buf_size );
> }
> 
> More importantly, this paves the way for dynamic driver selection at runtime
> (which is what you're really trying to implement with all that #ifdef crud).
> The body of esd_audio_write becomes:
> 
> return esd_audio_write[ esd_driver_index ]( buffer, buf_size );
> 
> For bonus points, implement the dynamic driver selection mechanism.  Linux
> machines could conceivable use oss, alsa, arts, nas, rplay, af, maybe more.
> Rig up esd_audio_init() to #ifdef around all the desired oss_audio_init(), 
> alsa_audio_init(), etc. Each *_audio_init() function adds the hooks for the
> driver specific functions into the global map, including a check to compare
> the argument given to -d on the command line, to see if it should be activated.
> 
> 
> 4. where arts has been added to the esd_audio_devices hooks, use "arts" instead 
> of "sound server aRts".  add a one line explanation to the help hook conditional
> on #ifdef DRIVER_ARTS

 Please explain this in more detail - which explanation do you propose and
where? If to the message esd prints when one invokes 'esd -h' - then it breaks
esd's tradition of not printing which sound system it's compiled for.

 Thanks for your input. Your comments on the latest version of the patch are
appreciated.


 Best regards,
  -Vlad

> 
> Vlad Harchev wrote:
> 
> > On Sat, 18 May 2002, Vlad Harchev wrote:
> > 
> >  Hello,
> > 
> >  The greatly polished and cleaned-up final version of the patch has been
> > attached to that bugzilla ticket -
> > 	http://bugzilla.gnome.org/show_bug.cgi?id=82154
> > 
> >  It's very compact now - it doesn't have any duplicate code. 
> >  Now it includes infrastructure for proxying sound to other sound servers
> > such as NAS and others - if one wants to implement it - feel free to ask for
> > advices.
> > 
> >  What do you think about this patch now?
> > 
> >  Best regards,
> >   -Vlad
> > 
> > 
> >> Hello, 
> >>
> >> It seems yet another step in cooperation between KDE and GNOME can be made
> >>now. Igor Mokrushin <igor at avtomir dot ru> has prepared a patch against latest
> >>ESD (Enlightened Sound Daemon) that makes it using ARts if ARts is already 
> >>started for the current user. 
> >> The patch doesn't require esd to be linked with arts libraries - it opens
> >>ARts C API library dynamically using dlopen(3). Full functionality of esd 
> >>(playing and recording) is supported if working via ARts. Majority of 
> >>sound APIs supported by esd are adapted for ARts use - only the HPUX sound
> >>system backend is not yet supported. Of course if ARts is not run for current
> >>user, esd will perform its functions in a usual way. 
> >> Essentially this patch allows GNOME apps (and other apps linked with esd lib)
> >>not to be mute if run under KDE.
> >>
> >> The patch looks clean. Whether the ESD can utilize is selected at compile 
> >>time is controlled by via yet another option for configure script.
> >> Since ARts libraries are loaded dynamically, the esd with this patch won't
> >>have a package dependancy on ARts; it even doesn't have build-time dependancy
> >>too!
> >> 
> >> The patch was placed in bugzilla:
> >>    http://bugzilla.gnome.org/show_bug.cgi?id=82154
> >>
> >> Please consider intergrating this patch into ESD distribution. It would be
> >>nice if it went into gnome2.
> >>
> >> Please forward this message to other mailing lists that you think are 
> >>appropriate.
> >>
> >> Best regards,
> >>  -Vlad