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