Subject: [linux-audio-dev] ALSA & aRts (Re: aRts C API ready!)
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Tue Apr 25 2000 - 20:56:47 EEST
Hi!
Well, so basically you want to have a layer which abstracts from aRts as
concrete sound server. You suggest ALSA. And you would like it to be source
(and binary) compatible.
Fine with me. ;-) - which of course doesn't mean that the other APIs that
aRts will provide are not a good idea. First of all: ALSA doesn't exist
on non-linux platforms. aRts has to be wider available. Then: aRts exists
for the reason to support advanced component like programming. It will allow
you to build virtual studios inside your sound server. It supports an advanced
streaming technology internally which is optimized at very fine grained
plugins, so you can run hundreds of small unit generators. Since it will
run as shared sound server, it will be able to provide low low latencies,
even to multiple cooperating apps.
So the aRts C and C++ layer will stay. The C layer currently supports only
a small part of what aRts can do. What could be discussed is extending the
aRts C layer to a universal sound server layer. It does already seperate
the interface library from an implementation library, which is dlopen()d.
If somebody wants to work on that (e.g. write a backend for another sound-
server), apps compiled against that universal sound server layer would run
with multiple sound servers. Any volunteers?
Back to source & binary compatibility with native linux apps. The two methods
used today are ALSA and OSS, while ALSA supports OSS emulation at kernel
level (Jaroslav, correct me about ALSA details, you are the expert there).
Then there is alsalib, which abstracts from the kernel API (which consists
of ioctls). As I see it there are four cases (when running ALSA):
1. OSS kernel api apps (which talk to the kernel via the OSS layer)
2. ALSA kernel api apps (which talk to the kernel via the ALSA layer)
apps using alsalib (which do not talk to the kernel directly)
3. using the pcm layer
4. using the pcm plugin layer
1./2.
=====
Staying completely user level, we can't support redirecting 1 and 2 to aRts,
as I see it. Of course, ALSA could catch the streams kernel level, and
redirect them back up to the user level, where a sound server could use a
special API to get the data. What would be the perfect compatibility with
anything would be if multiple apps could open /dev/dsp even in OSS mode and
of course the ALSA devices, and streams would be tagged with the application
name and reposted to aRts in user space.
If ALSA will support this, fine, so I'll add the code to aRts, if its not
very, very complicated. However, I think it is probably overkill.
3.
==
There are problems with 3, namely that the apps can get the file descriptor
directly. To illustrate: aRts currently uses a packet oriented protocol.
If apps want to write, but the stream is currently filled, they would need
to select *for reading*, to get a notification when they can write again.
What I'd suggest here is if we want to encourage using this layer, the ALSA
API should maybe look somewhat more like the X11 API. You can get the file
descriptor, but if you do, you have to select for whatever the API tells you
(e.g. it tells you if you should select for reading or writing), and if you
got something, you have to call snd_process_next_event(fd) maybe similar
to XNextEvent, XConnectionNumber.
There will be problems with sound servers which use shared memory and
semaphores for instance for communication (I thought about supporting this
some day for aRts).
4.
==
The pcm_plugin layer looks like it could be implemented against aRts with
no problems. I am not sure about the snd_pcm_plugin_pointer routine. So
here are some questions:
- How many apps use the pcm_plugin layer instead of the "pure" access?
Only those would benefit from having aRts there.
- Could ALSA maybe actively try to get rid of apps using the "pure" access?
I mean: if using pure access has no significant advantages, maybe it
would be good to mark it as *do not use this unless you really really
need to*..
- How would distribution look? Could you, Jaroslav, add hooks for dynamically
extending alsalib with .so modules for implementing the snd_pcm_plugin_*
interface? Are they already there? Is there example code?
- Or: should I patch alsalib directly? Any recommendations where ;-)?
- Could alsalib be made compile without ALSA kernel drivers (for non-linux-
platforms)? Does it already?
So as I said, I see supporting 4. (in userspace) would be a nice idea. Maybe
3., too, depending on whether it can be supported completely enough by a
user space sound server.
Finally, a few general things about what is the right thing to do. I don't
think the C api is "wrong". One size doesn't fit all. Thus there are various
levels at which apps will be able to access aRts.
- via MCOP/C++ interface (which is the most powerful)
- via dynamic (MCOP/C++) plugin loading (running inside the sound server: fast)
- via the aRts C API
As I said, many apps already come with five or ten drivers for audio, so
adding a conditionally compiled aRts C driver is probably the least work
for them.
- via support in meta audio libs:
Lots of apps don't do audio in any direct way, for instance quite some use
SDL. I hope there will be aRts support in such meta libs, so all apps using
them will automatically support aRts. ALSALIB support falls in that
category, too, and I'd really like to see it. ;-)
Ultimately, the application writers will choose what they want to use. I think
we should move this to the ALSA list now, as it seems to be an ALSA only issue.
Cu... Stefan
On Tue, Apr 25, 2000 at 03:56:03PM +0200, Benno Senoner wrote:
> Stefan,
> I appreciate your efforts, but in my opinion, the ideal thing
> would be to have a layer inside ALSA (is the plugin layer suitable for this?)
> to let redirect apps from direct output to your foobar soundserver.
> Recoding the apps by outputting directly to arts is not the right thing to do,
> since:
> - there may be many soundservers around,
> - the effort to port zillions of apps is simply too big
> - there are many binary-only apps which can not be changed.
>
> I think ALSA is and will be the de-facto audio API which all Linux
> apps should use.
> That means if one wants to go through Arts, that should be
> user-transparent.
> The only problem of such hookups it so handle fragment num,
> fragment sizes, wordlen, samplefrequencies etc correcly,
> and that has to be taken into account in the soundserver too, not only in the
> redirector layer/plugin.
>
> BTW writing an ALSA redirector for every soundserver, would allow us
> to run ALSA apps on any system, be it direct audio, esd, Arts etc.
>
> > for public use. This means, you can now grab any software package you
> > like and turn it into an aRts aware software package with a few lines
> > of code. ;-)
>
> the gaol is ZERO lines of code.
>
> comments ?
> (Jaroslav are my assumptions reasonable ?)
>
> Benno.
>
>
> On Mon, 24 Apr 2000, Stefan Westerfeld wrote:
> > Hi!
> >
> > I am happy to announce that the aRts C API - which allows you to send
> > streams of samples to the aRts sound server using plain C - is ready
> >
> > Background: artsd is a sound server based on the aRts/MCOP multimedia
> > component technology. A sound server allows you to let many applications
> > use the audio device at the same time. So it allows you do listen to
> > music, while still playing a game. For instance, you can now play Quake
> > and listen to mp3s. And still get an audible notification when you got
> > new email. Of course, this is much more fun when more applications are
> > aRts aware.
> >
> > To show how easy porting is this, I did the port for two apps, namely
> >
> > - Quake (patch against quakeforge-0.1.1) => it has good response times ;-)
> > - Mpg123 (patch against mpg123-0.59r)
> >
> > It was really little work (besides writing the API of course). The snd_arts.c
> > driver for quake for instance is the smallest of all sound drivers with
> > about 160 lines of code, which are mostly copied from the other quake
> > sound drivers.
> >
> > The necessary aRts code is in the KDE-2.0 CVS where the other aRts stuff
> > lives. But there are also standalone snapshots, which dont require X11,
> > Qt or KDE to work. The snapshots are available at:
> >
> > http://space.twc.de/~stefan/kde/arts-snapshot-doc.html
> >
> > And here is the URL where you can documentation for the C API & the patches:
> >
> > http://space.twc.de/~stefan/kde/arts-mcop-doc/artsc.html
> >
> > Any comments to the API or more patches are of course welcome. Expect the
> > first "official" releases of aRts soon.
> >
> > Cu... Stefan
> > --
> > -* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
> > KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Tue Apr 25 2000 - 20:41:36 EEST