glib dependancy in KDE3.x

Josef Weidendorfer Josef.Weidendorfer at gmx.de
Fri Mar 7 14:39:10 GMT 2003


On Thursday 06 March 2003 17:40, Alexander Kellett wrote:
> On Thu, Mar 06, 2003 at 05:25:57PM +0100, Alexander Neundorf wrote:
> > Yes, but IMHO (and maybe a lot of others) it should be optional.
> > I have a simple SB (es1371) sound card with /dev/dsp1 and /dev/dsp2, for
> > me this is really enough. I can run xmms on /dev/dsp2 and all other apps
> > can put stuff into /dev/dsp. Even without this I didn't run arts, I don't
> > need it, /dev/dsp works perfectly for me.
>
> cool. never realized my last soundcard could do this :)

For me it's the same: I have a cheap SB Live, and with the ALSA driver, apps 
can open /dev/dsp 32x simultaniously! There's really no need for slow 
software mixing of audio data: Every KDE app should access /dev/dsp on its 
own. Can't arts detect the features of the audio card and switch off software 
mixing of not needed?

Of course, some kind of audio server for network transparancy is usefull. But 
this could be a runtime option.

> > How about splitting arts in some way so that only the arts libs which are
> > needed to build the rest of KDE are included in arts/ and the rest in
> > kdemultimedia/ or kdebase/ or whatever ? Or a config switch for arts/
> > --build-only-really-required-stuff ? ;-)
>
> couldn't agree more. wouldn't it be possible to
> do a "/dev/null" arts replacement for the sound
> stuff in kde?

Why not have a kicker applet with the wave of the sound to be produced?
You could put the antenna of your radio to this applet and here the sound...

Josef

>
> mvg,
> Alex






More information about the kde-core-devel mailing list