Slashdot Mirror
A Sound Server For X
An anonymous reader writes "X.org, the organization that governs the evolution of the X11R6 specifications, has released a sound server for X, called MAS. According to their site: 'MAS integrates with a compatible X11 server on your desktop. It processes graphic information locally, alleviating the need for network transmission of uncompressed graphical content. Graphic events are easily synchronized with audio events for professional-quality multimedia and accessibility-enabled applications.'" The X.org site describes MAS as an "affiliated technology" rather than "official," but it is released under the same license. "MAS" stands for "Media Application Server," and it's developed by Shiman Associates.
There are already a bunch of remote sound servers. I happen to like rplay, but there is also artsd, nas, esd, etc... Was the problem simply NIH syndrome?
From all the experience I've had with X applications, a sound server is the first thing that they need.
I've used a lot of X apps that have crashed due to bad requests (especially those dealing with unsupported colourmaps), and it makes sense that someone would shore up the current state of the code and work on stability. But why has it taken so long?
At any rate, this is a good step forward--hopefully we'll see more X-based apps improved as to stability and speed (X isn't the speediest thing in the world).
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
Can those knowledgeable with the aRts sound server stand up and tell us what this means for Linux and KDE. Is this a better approach or is aRTs better?
Lots of neat applications, actually. One of my favorites is a network monitoring room... For instance: network monitoring apps sample your network traffic once a second... while bandwidth and processor utilization of your servers is within preset values, an audio file of a creek is played over your X-enabled speaker system. When congestion occurs, you here a new audio file played (which is, of course, mixed into the original creek audio-file) of a herd of cows drinking water, or something... When a router or server goes down, an alarm is triggered, and a flock of crows start caw-ing; or an elephant trumpets, or whatever...
The point is, when everything is going fine, the audio environment of your network control room sounds like a peacefull woodland setting, or something. When something goes wrong, you hear the animals going crazy. It's a really, really great way to monitor a large network, without being glued to a network monitor all the time.
Typically, an X-server would alert you to each of these above mentioned alerts and statistics by displaying a video-file of some sort, which is displayed on your video monitor (CRT, LCD). With an X-sound-server, you can pipe the same alerts and statistics to audio-files which are 'displayed' on your sound monitors (speakers).
If XMMS is using that much, then it is seriously broken. Admittedly, X *can* use a lot of bandwidth, but the onus for this is almost entirely on the application (toolkit) developer. Gtk+ and QT used to be really bad at this, but have since improved dramatically. Even so, there are a lot of variables to consider and using a light-weight theme in your respective toolkit can make a large impact on network performance.
When I work from home, I do so *entirely* out of an ssh-forwarded X connection, including, but not limited to, multiple XEmacs sessions, terminals and occasionally a remote Mozilla. The *only* problems I have encountered involved XEmacs doing silly things with the cut-buffer and pausing momentarily.
I am, admittedly, not an expert on the X11 wire protocol, but from what I have read from those who are, it is not inherently bandwidth heavy, but any protocol can be abused.
Additionally, sound is surprisingly light on a LAN. Doing some tests with K12LTSP esd integration Eric Harrison discovered that streaming audio frequently takes up less bandwidth than moving a window in "opaque" mode (contents continually updated)
Let's hope that there's intelligent life somewhere out in space 'Cause there's bugger-all down here on Earth.
The last big push from the Open Group was Broadway, which was an X protocol based plugin for web browsers. Look at how popular it is today! Their XPrint work is just as successful.
I am a composer/musician using Linux for my needs and from what I've seen so far all of the aforementioned servers esd, asd, artsd etc. are rather rudimentary and incomplete. Furthermore they have monstrous latencies (which is a big problem for any kind of time-sensitive interactive music).
To this date the best audio server on Linux is JACK, but unfortunately just as any other of the current servers, it is still under development. Nonetheless, its advantages over the given bunch of audio servers is immeasurable:
1) absolutely the best latencies (including even other OS's) down to 2.5-3 milliseconds (you need to patch the kernel for low-latency operation though since the vanilla Linux kernel 2.4 and down has some big issues with the scheduler). All this is achievable even with the current version, even though it is under development.
2) integration where the signal could be routed not only to the dsp but also between the apps (so you could theoretically get the signal routed from xmms into your real-time sound processing app and then to the audio recorder and audio output).
3) Relatively easy to implement and allowing for practically unlimited number of connects
4) Relatively low overhead
Unfortunately, as I mentioned before it is still under development and has its own issues that need attention. Furthermore, apps need to be adapted to be compatible with this server (in another words this server is not trying to be compatible with older servers simply because they are inferior, dead-end kinds of implementations). That being said, it is still the best sound server around.
I would really like to see Linux community let the audio programmers/musicians to provide solution to this issue, because they are the ones who know the best how to create the best possible sound server that will suit their highly demanding needs and yet provide a great architecture for the rest of the casual users.
It is unfortunate though that instead of unifying our efforts everyone feels like they need to make a brand new implementation of the same idea instead of contributing to the projects that are already semi-mature and need further assistance in development. Because of this "so-called-diversity" we now have half-dozen sound servers out of which 90% blow chunks, while the other 10% have a great potential but are incomplete.
I got excited when I read the word "synchronized"
thinking this might be a mixer with SMPTE timecode capabilities. One of the most important distinctions between "pro" A/V and "consumer" A/V is whether the tracks have a standard sync encoding. Without that, the best you can hope for is "close", and that is not acceptable for broadcast or production.
This requirement is serious enough that pro gear has an input for a real hardware clock.
Sync capabilities and clock controlled sampling are a few of the keys to us having pro audio production on inexpensive hardware. Unfortunately, the barriers to entry remain outrageously high.
For most PC users, the sound card is strictly an output device. few will spend more than $100.00 on it, and even fewer will have audio tracks for which the bitrate or noise floor of these cards is a limiting factor. We tend to regard the sound card as a device for playing back audio that is at most, 44.1Khz, and at the deepest, 16 bit.
For the rest, the sound card is an input device. As such, it theoretically could be as good an input device as that found on a $100,000 audio workstation, and there isn't really a good reason why we CAN'T make the poor-man's DAW if we use one of the better sound cards as a starting point.
A timecoded 24-bit audio track which has not been resampled for the finished output is a minimum for "professional" work, and we *almost* have it on consumer gear! Everything except real timecode.
I place this problem in the same category as the absense of colorspace management on The Gimp. Those who understand what it is, realize that it makes the difference of whether they can use it professionally; those who do not understand, don't care, and don't realize the magnitude of the problem.
Slightly offtopic, but I figured I might as well take a shot- Has anyone successfuly piped audio from a Unix machine to a windows machine, across the network? I got it working using esd and a java version of esd, however the sound quality sucked (and java's sound support didn't like my 5.1 sound, I wouldn't mind but it had 0 bass).
I've looked but can not find a native sound server for windows at all, in any form. Even somthing compiled with cygwin would probably work, but no luck there either.
With your line of logic we should still be using the Bi-plane.
.222 can supply the whole war for several months, which is exactly what happened, JUST as they were going into general service.
One of the things an experienced engineer is better at than a newbie is knowing WHEN to use a well-known, well-debugged solution, and WHEN to go invent a new one.
It is unthinking reinvention that led to abortions like BART, which I could deconstruct at length. Hint: Using aerospace engineers - whose only experience with wheels-on-surface is landing gear - to reinvent the train results in discarding nearly two centuries of well-debugged solutions and gives you a very rough ride. And an expensive one: The only manufacturer of new rolling stock is in France, and charges over 6 million bux for a single car.
Another case is the old AK-47 verses the M16 debate. Yes the M16 shoots straighter, and farther. But the AK-47 can be repaired in the field, has a higher rate of fire, and is dirt cheap to make. Depending on your needs, one works or the other.
If given proper ammunition the M16 does very well in the field and doesn't NEED repair. And the gas system is self-cleaning, so you don't need to take it down and clean it in the field. Just keep reloading and firing.
Unfortunately, immediately after its introduction an admiral decided to have a bunch of going-out-of-date ball powder for naval guns remanufactured into rounds for he M16. Now a single round of a big navy gun uses a LOT more powder than a single round of an M16 - so one lot of power redone as
Given the correct powder the M16's gas system is self-cleaning. But fouling isn't a big problem for a navy biggun, so not leaving a cloud of carbon wasn't high on the design parameters for ship gun powder. So the out-of-spec rounds smoked something fierce, to the point that firing a few boxes totally clogged the gas system, turning the M16 into a single-shot slide-action, typically at some inopportune moment when it was being used heavily.
So the M16 got a rep as a tight-tolerance jam-prone turkey. Once the problem with the out-of-spec powder was discovered (and a few heads quietly rolled) the M16s stopped jamming and no longer needed to be "repaired in the field".
AKs were designed by a (genius) wounded sergant in WWII, to be manufacturable with the level of steelmaking available in Russia while their still-primitive infrastructure was being pounded by the Germans. They are a solid, reliable, full-auto that could be built to tolerances achievable under such adverse conditions, enabling Russia to rearm its soldiers (which were mostly using bolt-actions at the time). The design stayed popular because it could be manufactured by any Soviet client state that was just starting to get steelmaking going. So it became the insurgents' weapon-of-choice.
But don't forget to clean them immediately after use, because much of the cold-war era ammo is corrosive-primed. And a rotted-out AK will die in action quite as effectively as a powder-fouled M16.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way