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

List:       kde-devel
Subject:    Re: aRts-OSS 0.1.0
From:       Richard Stevens <mail () richardstevens ! de>
Date:       2001-11-27 0:59:57
[Download RAW message or body]

-----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 ;)

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?

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...

Thanks,

Richard
- -- 
- ---
http://www.richardstevens.de

Unix IS user friendly, it is just selective about who his friends are.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwC5Y4ACgkQWQvEMJfcXlTFSgCcDKDWerTRgGFeEzMiP31OIB+Y
r4QAoJkTq1Mz0JroFS6Axef9NN9Qqqn5
=njvU
-----END PGP SIGNATURE-----

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

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