On Saturday 12 February 2005 05:42 pm, Holly Bostick <[EMAIL PROTECTED]> 
wrote:
> Boyd Stephen Smith Jr. wrote:
> > There are 4 use flags that concern me: oss alsa esd arts.
> > [I suppose there are other use flags out there, like jack and maybe
> > dmix in the future, but I'm not worried about those ATM.]
> >
> > What I'd like to do is have programs that support arts (have an arts
> > use flag) compile support for arts, but none of the others.  Then, any
> > that support esd but not arts (have an esd use flag, but no arts use
> > flag) compile support for esd and no others.  Then, alsa and finally
> > oss (although I'll have oss apps use arts through the compatability
> > layer.)
>
> I may be missing something, but how do you expect +arts to work without
> +alsa (or +oss)?

Arts would output to esd.
Esd would output to alsa.
Alsa would deal with the card(s) directly.
Oss would really be the alsa oss compatibility layer.

I would have all 3 packages installed (arts, esound, and 
gentoo-dev-sources).

> If an app has a +esd and not a +arts, then having +arts 
> in your USE flags doesn't matter, because no app is going to compile
> support for something it doesn't have.

Right, but if an app has esd and arts flags having +esd will cause it to 
compile in support for talking to esd directly, which I will never use.

> If an app has +oss, but you only 
> have alsa drivers in use by the system, all this does is allow alsa to
> /inform alsa that this program will use the compatibility layer (rather
> than direct alsa use). If you compile -alsa and you only have alsa
> drivers in use by the system, that program will have no sound.

Again: but if an app has alsa and oss flags having +oss will cause it to 
compile in support for using the oss intrface, which I will never use.

> About the only thing I can see this complicated hypothesis avoiding is
> having all forms of support being compiled for a single app, but I see no
> reason why you would want to avoid this, unless you specifically were
> not going to have one of these elements on your system.

I want to save on compile time and package size.  If an application as 
arts, esd, alsa, and oss flags, I'm only going to use it's arts support so 
I want it compile with +arts -esd -alsa -oss.

> So, since arts, esd, alsa and alsa OSS support are already on your
> system, why does it matter that individual programs do not have the
> broadest range of support possible?

It takes extra time to compile that support each time the programs are 
updated and it takes extra HD space to store those support modules *which 
I will never need*.

===

I suppose I was unclear.  I want each app to only compile in support for 
one of these services.  That way, the unneeded services do not extend my 
compile time or prouduce unnecessary run-time configuration options.  (I'm 
on a PII 450, so compiling is a bit slow.)

Here's a grid, I only want support compiled for the sound system listed in 
the rightmost column based on the use flags:

        Use Flags       | Compile
-----+-----+------+-----+ support
arts | esd | alsa | oss |   for
-----+-----+------+-----+--------
 no  | no  |  no  | no  | none
 no  | no  |  no  | yes | oss
 no  | no  | yes  | no  | alsa
 no  | no  | yes  | yes | alsa
 no  | yes |  no  | no  | esd
 no  | yes |  no  | yes | esd
 no  | yes | yes  | no  | esd
 no  | yes | yes  | yes | esd
yes  | no  |  no  | no  | arts
yes  | no  |  no  | yes | arts
yes  | no  | yes  | no  | arts
yes  | no  | yes  | yes | arts
yes  | yes |  no  | no  | arts
yes  | yes |  no  | yes | arts
yes  | yes | yes  | no  | arts
yes  | yes | yes  | yes | arts

> > Is there a simple way to do this, or do I have to go through all my
> > packages to set my use flags in package.use manually?
>
> Well, I would say just use all of them and let it sort itself out, but
> then again, I don't get what you're trying to do here.

I am using all of them, right now.  However, I'm hoping to save some 
compile time on upgrades.  Also, it'll save some disk space since I'm not 
going to be using the various other output devices/plugins available.  For 
example, xmms has 3 or more output plugins I'm not using, so does arts.

> > AFAICT, I have to have arts to get sounds from most KDE apps and I
> > have to have esd to get sound from flash so I'm thinking my sound
> > setup should be somthing like:
> > arts -> esd -> alsa
> >         oss ---^
>
> Arts doesn't "use" esd (they are two separate sound servers which
> perform parallel functions) so "arts => esd" is not reasonable. The
> situation is more like this

This is absolutely incorrect.  If you compile arts with esd support arts 
will allow you do chose "Enlighted Sound Daemon" as your output device 
resulting in arts using esd.  I'm doing that *now*.

While you can have both arts and esd use alsa directly, I believe there is 
less device contention if you have arts use esd.

> Are you sure that flash won't play sounds if esd is not running? I don't
> have esd running atm, and I haven't noticed any problems with Flash in
> my browser (and my browser isn't even Konqueror, which I would have to
> believe should handle sound-producing content through arts). But then
> again I'm not in Gentoo atm, either. What USE flags was
> netscape-flash-plugin compiled with? Or the browser that you are using
> to display Flash?

I'm using www-netscape/netscape-flash 7.0.25.  It only has one use flag 
available, gtk, which I have turned on.  Initially I had sound, but none 
from flash and, IIRC, a forum post said that netscape-flash required esd 
to play sound; installing esd did cause flash to play sound.  I'm using 
the latest ~x86 ebuild of firefox.

-- 
Boyd Stephen Smith Jr.
[EMAIL PROTECTED]
ICQ: 514984 YM/AIM: DaTwinkDaddy

--
[email protected] mailing list

Reply via email to