Next Previous Table of Contents
You have only one soundcard, but you have an operating system that allows you to run fifty applications at a time. In an classic environment, only one of them may read/write the audio hardware, since there is only one /dev/dsp device provided by linux.
Still, that problem has been solved elegantly in another domain. You have probably only one graphic adapter, but you can run fifty applications at a time, each of them in an own window. You have a window manager to choose what you want to see where, you have a panel, that helps you starting new stuff, you have a window manager, probably virtual desktops and whatnot. As you see, a window system like X11 solves the issue really elegantly.
The idea of a "generic audio server" like I call it, is to come up with a similar solution like X11 for audio. That means one server should get access to the soundcard, while all other applications read and write from/to the soundcard only by this server.
But stop. Why again? You probably already was told that esd would do that, or that kaudioserver solves just that problem. Why reinvent the wheel?
Basically, what they do is adding up all the streams that are incoming, and they provide recording and sample playing abilities. While they are good at that (and reasonably optimized at that particular task), their concepts don't reach far enough to provide more complex applications with their services.
Something like AudioLogic simply couldn't use ESD or KAudioServer to perform it's task.
To use the analogy to X11, these "simple" audioservers are like having multiple linux consoles with SVGALib. While that solves the problem that you only can run one application at a time, it doesn't provide a great way of using them together. They have no concepts for management, interaction, synchronization, midi stuff, filters (or only small parts implemented), ...
On the other hand, aRts isn't lacking many features that would make it able to be a "generic audio server" in the same way ESD or KAudioserver are.
The benefits of going that way are, that in aRts, lots of issues have already been solved and lots of technology is available. That is for instance:
So the idea would be to try to make aRts suitable for an all the time present, generic audio server, which would in turn be able to offer service to applications which are more complex than a simple mp3 player, such as someling like AudioLogic or CuBase.
aRts could in the long run become some DirectSound replacement for the platforms it runs on, allowing multiple applications to interact realtimely through a shared flow system.
Of course, besides the complex applications, aRts mainly must be able to fulfill the tasks that ESD/KAudioServer did reasonably. Lets look at an mp3 player, and how the newly written artscat tries to provide first "generic audio server" services here.
In a perfect world, the audioserver (that is: aRts) would know anyway what mp3s are, and further, in a perfect world, a playing framework for media like mp3s would exist inside the audioserver, and there simply wouldn't be a mp3 player, since aRts itself could pop up a nice screen with controls and play the mp3.
Unfortunately, that perfect world isn't quite the same thing as the world we're living in now. So we need something else until we are there.
Fortunately, an mp3 player doesn't require much for playing. It reads some file, perhaps paints a window (or not), and finally sends the stream to the soundcard. What we can do here is: let him send the stream to aRts instead. Then aRts can pick it up and route it through mixers, effects, busses, feedback loops and whatever. And finally send it to the soundcard.
New aRts releases (>= 0.3.3) allow that. There is a small utility called artscat, which picks up a stream of bytes from stdin and sends it to aRts via TCP (no CORBA for transport since that would be way too slow). Artscat has the following syntax:
artscat -d <description> -t <type>
while type and description are used for the user to see whats going on and may be used in some later aRts version for automatically assigning channels to certain services...
On the other side, the stream will get picked up. The user can choose with an Gui_AUDIO_MANAGER widget to which bus send the data (look at the artsshell options -c and -d if you want to know how to achieve the same assignment functionality from shell instead of artsbuilder). To supply a practic test case, a shell script called artsmp3 has been written. If you have mpg123 installed, you can now simply type
artsmp3 <filename>
It will use artscat to send your stream to the server. It will open a konsole window to display its output. It works nicely if you have a mixer on your screen (try the example_mixer_eq example), so you can mix your mp3 with something else. For instance with a live improvisation you are playing on your keyboard.
Or with another mp3. I have succeeded in playing 9 mp3s at the same time through aRts on a PII/350. Perhaps that's not really useful, but it shows that the technology behind it is stable. There were no klicks and breaks. But I must admit I didn't use a mixer to save CPU power... with mixer there are probably some channels less possible.
As artscat is written and the next steps would be:
Support recording through aRts. The main difficulty here is that aRts would need to read/write from/to a full duplex sound card, while still being able to evaluate its signal flows. That was always planned anyway, and now would be the time to implement it.
Then, artsrec should be as straightforward to write as artscat.
Well, esd supports monitoring what was mixed together, but since artsrec should be able to record data from any point in the flow system, it may as well record the data shortly before playing it. So
ln -s artsrec artsmon
Both, esd & KAudioserver allow programs to store samples in the audio server, which then can be replayed with a short command. This really should be no problem to implement, as aRts can already play WAVs anyway.
While the CORBA interface may be ok for some people, for most it will be too ugly. So there should be a wrapper library around it that supports easy access to aRts.
On the other hand it would be nice to have backward compatibility to the old APIs, perhaps even to the protocol.
Well, and if thats dont, one could try to add extra bells and whistles since aRts can do a lot more than simply mixing streams together. The equalizer supplied with the current aRts gives an idea whats possible.
Next Previous Table of Contents