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

List:       arts
Subject:    Re: Why aRts? When we have ALSA?
From:       "kreuzritter2000 gmx.de" <kreuzritter2000 () gmx ! de>
Date:       2001-07-16 15:36:08
[Download RAW message or body]

> Since no one else responded to this, I'll try answering.

Thank you for answering. :)

> On July 14, 2001 03:30 pm, kreuzritter2000 gmx.de wrote:
>> What's the point with all this, aRts and alsa?

> ALSA is primarily a set of kernel drivers for sound cards, although
> with the ALSA library it does some higher level functions too.

> aRts is a higher level library that sits on top of the sound drivers.
> It provides features like:
> - a sound server that allows multiple applications to share hardware
> services
> - a portable (across different hardware and operating systems),
> object-oriented,
>   language-independent set of APIs
> - network transparency and authentication
> - rich functionality (e.g. flow system for connecting modules, many
> predefined
>   audio modules, codecs for most common audio formats)
> - an architecture that can be extended to other streaming media such as
>   video

The issue with the platform idependence sounds good.


>> 2. The next quesion ist the following:
>>
>>
>> In the arts manual handbook it says, that the alsa driver can be used
>> with
>> aRts, but only in OSS compatibily mode.
>>
>> But OSS is only a primitve input/output sound driver architecture that
>> doesn't use the special hardware features of good professional
>> soundcards.
>>
>> So when arts is only using OSS, does this mean that it makes the hardware
>> effects of a good soundcard useless?

> Yes, when using OSS any sound card features not supported but OSS
> won't be used by aRts, although  aRts may provide some of the same
> functions
> less efficiently in software.

That's sad to hear.
For example mixing sound channels via the soundcard hardware
is a lot faster then with the arts software sound-server.
And when it comes to games like quake3 or so, then i think the hardware
way is a lot better.
 

> There is now an ALSA back-end for OSS, so the statement in the handbook
> is no longer correct. If ALSA is present when aRts is built then it should
> use
> the ALSA backend (you may have to specify using ALSA when you start
> artsd if OSS is also present). I'm not familiar with the aRts ALSA
> backend,
> so I don't know if it uses any ALSA-specific special hardware features.

Hm, so using the ALSA backend for OSS means , that
not the whole features of ALSA are used. Only OSS specific fetures. ;(



>> Is it planed to make aRts capable of using the hardware effects of the
>> soundcard(by using the alsa-drivers and library) for some effects instead
>> of using the arts-software-only modules?
>>
>> I asked this, because it saves cpu power and doesn't make good soundcards
>> obsolute.

> That depends on the definition of planned :-) Some features are mapped out
> but like most open source projects, the work only gets done if someone
> steps forward and volunteers to do it. aRts could make use of more of the
> ALSA-specifc features,  but no one has stepped forward to do it.  Since
> ALSA
> is not (yet) in the standard kernel, spending a lot of effort on
> ALSA-specific
> features is probably not a high priority. You would also have to handle
> the
> case where an application wants to use a feature that the sound card is
> not capable of (maybe emulate it in software, for example). I also
> understood
> that the ALSA APIs may not be that stable yet, so relying on things that
> could
> change would break aRts.

I hope arts will use some ALSA features by using the hardware of the soundcard in future.
Perhaps the chances are good when the ALSA library is stable and has reached version number 1.0.

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