[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: aRts-OSS 0.1.0
From:       Charles Samuels <charles () kde ! org>
Date:       2001-11-27 1:11:06
[Download RAW message or body]

On Monday 26 November 2001 04:59 pm, Richard Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > - Could you give more information about the aim of this inclusion in the
> >   kernel, the advantages / drawbacks, etc. The reasons you gave here are
> >   not that useful to me... more, I don't really understand what
> > LD_PRELOAD has to do with aRts and soundcard access. Your brief
> > explanation are a bit confused, or I'm completely wrong about what you
> > meant. From what I understood, I see something like : userland -> kernel
> > -> userland -> kernel, and it doesn't make any sense to me...
>
> Hi,
>
> I'm not sure if I get it completely right, so correct me if I'm wrong.
>
> First, usually only one application can access the oss device for playing
> sound. Arts is capable of mixing the soundoutput of multiple sources
> (applications). You can ie. hear the incoming message on ICQ while
> listening to mp3s. There is a way to have non arts enabled applications
> (wich can only access oss devices) emit sound through arts. You can do
> artsdsp appxyz and appxyz can access some virtual oss device for output. In
> fact it's not accessing it but a library intercepts the oss stuff and pipes
> it to arts. Maybe some conversion takes place underway. I wouldn't know.
> The library is loaded with LD_PRELOAD. That means as far as I understood
> it, load the library before the application links to the library it uses.
> Having something like that in the kernel would enable virtual dsp devices
> and you wouldn't have to use the artsdsp app or the LD_PRELOAD mechanism. 
> Sound is now arriving from the application (userland) to the kernel (new
> module) back to userland (artsd) back to the kernel (artsd accesses the
> real oss device) right through your soundcard out to your speakers.
>
> Was that at least close to what's really happening ??? ;) Hope so ;)

Yes, that's what's happening

>
> I've got another question myself. The new module runs in kernelspace right.
> What happens if it tries to access arts and arts died for some reason. Most
> applications I know have serious problems with that. I'm worried about not
> only a blocked application but a blocked kernel...
>
> Or does that module operate artsfailureproof?

All this does is take audio from kernelspace and make it available to user 
space.  Then there's another app (arts-kserv) that grabs the audio from the 
kernel and sends it to aRts.


>
> Wouldn't the best thing be something like arts within the kernel? Sounds
> like the ultimate solution to me. Then again... I'm not a kernel developer
> at all...

I would not agree with that, since arts is much more than just a sound 
multiplexer, and that's way too complex for the kernel.



 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]