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)
ESound? Asd? ARTs? It seems a little different in concept, but I just can't get it. If it is, so cheers to the guys that made it... Linux at least (as I understand this is for X, so *BSDs and other *nix should benefit too) need a more standardized sound architecture (Yeah, I know about ALSA, but I mean something more higher level - like DirectSound)
It processes graphic information locally, alleviating the need for network transmission of uncompressed graphical content.
Since it relies on X11 I suspect the bandwidth requirements are going to be really high. X11 over the network is a bandwidth hog, that's all there is to it. Now they're adding sound?
X11 needs a new protocol. Graphical applications run across the network consume ridiculous amounts of bandwidth. If you want to do a test try running the XMMS gui across the network via X11. The last time I did it, XMMS was using 11 megabits per second. It would really suck to try that over a modem or a 64K frame-relay link.
Great, all the people who think X is too bloated as it is will now be crying "No mas!"
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).
Thats the real question...
Today is a gift. Save the receipt.
There is already a MAS associated with audio -- MOTU Audio System plugins.l obal/index .html)
(http://www.motu.com/english/software/g
Perhaps they should have done a bit of name research.
A sound, solid server will certainly help with all sorts of stability problems I've experienced with X over the years.
... you meant sound as in audio? Oh, nevermind.
Oh wait
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.
What does the National Institutes of Health have to do with this? :_|
NIH = Not Invented Here. (Implication: So let's ignore it and reinvent this wheel our own way. Like maybe without that obnoxious radial symmetry. Besides, a round wheel might violate some patent. So let's have lots of engineer fun and waste lots of money, instead of pulling an existing design off the shelf, filing off a few rough spots so it will fit, and installing it.)
NIH goes along with management that thinks you need young developers who are constantly creating (and will reinvent the bubble sort), rather than experienced developers who already have the answers in the can (and will pull down their copy of Knuth Vol III and pick the right sort for the job.)
Which is not to say that I agree with the poster's conclusion that they may be ignoring fine solutions in order to construct one of their own. Integrating the video and audio server and protocols - rather than grafting audio onto an existing video server (which is in turn grafted onto something originally designed for more static displays) - is the right solution for synchronized video/audio. And the integration may have different problems than gluing the bag onto the side of the kludge.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
And for those who are asking what's wrong with existing sound servers: there's no standard mechanism to query whether one of them is running, especially on a remote machine. (No, relying on magic port numbers is wrong.) And not all of these servers run under all Unix variants. I personally have had very hard time trying to make aRTs work under comercial unices. With this stuff you just talk to X server. There's hope big players will support it because X is the industry standard. esd, to put it bluntly, isn't.
No. The X clipboard takes some used to (text copied with left button is different from text that is copied from ctrl+c), but it's been standard for over a decade.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
Key features of the Network Audio System include:
- Device-independent audio over the network
- Lots of audio file and data formats
- Can store sounds in server for rapid replay
- Extensive mixing, separating, and manipulation of audio data
- Simultaneous use of audio devices by multiple applications
- Use by a growing number of ISVs
- Small size
- Free! No obnoxious licensing terms
Applications that support NAS natively:- Festival - The Festival Speech Synthesis System.
- mpg123 - a command line MP3 player
- GAIM - a free AOL IM client
- OpenOffice (StarOffice) - the (now opensourced) StarOffice Suite has built-in NAS support for the Solaris and Linux Platforms.
- The Qt Library - from Trolltech supports NAS natively. You will need to pass the '-system-nas-sound' to './configure' before building.
- libSDL - SDL, the Simple DirectMedia Layer library, now has native NAS support thanks to Erik Inge Bols\x{00F8}
- XAnim - the X Animation viewer
- XBoing - a blockout type X game
- XPilot - a multiplayer client/server space warfare game
- Xemacs - the best cross-plaform, cross-language IDE
- Alsaplayer - A NAS Output plugin written by Erik Inge Bols\x{00F8} is now supplied with the Alsaplayer distribution.
- X MultiMedia System (XMMS). A NAS Output plugin written by Willem Monsuwe is available at ftp://ftp.stack.nl/pub/users/willem/
- Wine. A NAS plugin written by Nicolas Escuder is now available with the WINE distrubution.
Not a trollLess is more !
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.
This major code release is only our first step. We're putting the MAS core out there in order to create a useful open standard. We feel that this code represents a radical departure from prior attempts to manage time-critical data on the desktop and across the network. We see this as a valid and innovative architecture with extensive implications for the management of media of all modes. In particular, one of the important applications of this architecture is to time-critical accessibility tasks which can now be handled in a completely generic fashion.
We encourage close examination of the code and we will do our best in the near term to bring as much of our insight and intention to the open community. We see this as an opportunity for collective and collaborative innovation.
From our website:
MAS will provide a complete mechanism for media support, for all pluri-modal media, for all platforms, for all operating systems, for all window systems.
MAS supports the desktop and, transparently, the network. In particular, MAS will provide complete support for the X Window System, across the network.
MAS is an open system: the complete core will remain under the original MIT ("X") license, equally supporting open and proprietary use and development.
MAS provides mechanisms for structured extension, and will be supported by dedicated testing and certification processes.
We wish explicitly to thank Sun Microsystems and X.org for their generous support.
Leon Shiman for the MAS Development Team
Well, we looked hard at the Network Audio System (NAS), and at DEC AudioFile, and esound and aRTs. And we looked hard at the efforts of Tice and Welch at the X Consortium whose X Common Audio project was to take the best of the NAS and DEC AudioFile to form the standard solution. And, we looked hard at all kinds of other soundserver-related things out there.
Our conclusion: none of them had the kind of system-pervasive time management one needs to handle sound, let alone video or other time-dependent information. The system that came closest to meeting our timing needs was DEC AudioFile, but it was not extensible enough for our needs, and lacked support for sample rate conversion.
We didn't take the conclusion lightly. As you say, there's all these applications that support the Network Audio System natively. There's all those old NCD X tubes that support it in firmware, too. And, I really have no interest in stepping away from code that has most of its bugs worked out. But, we just did not see how NAS would scale in both performance and in functionality to handle the kind of high-performance multi-media we all want to see on Linux and UNIX.
I think MAS is a great platform to handle the timing. It's young, though. We're working hard now on a soundserver-style API to ride on top of the lower level core API that's in the source distribution. Beyond that, there are a host of security issues to work through, and the X.org standards process. (Also on our to-do list is a more detailed developement roadmap for the website!)
I think there's a ton of cool, useful stuff in the core of MAS now. For instance, we compute a running estimate of your soundcard's actual sampling rate. You can use that estimate to drive the sample rate converter (srate) device to resample audio to the actual rate of your sound card. We've been appalled at how far off some soundcards' crystals have been!
Please be patient if you e-mail us... We're getting a lot of e-mails for some reason.
Thanks,
Mike Andrews
Lead Developer, Media Application Server (MAS) Project