A Sound Server For X 226
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.
What's wrong with the old ones? (Score:5, Interesting)
Re:What's wrong with the old ones? (Score:5, Informative)
can send audio data over a number of different transports, including CORE X
I could go on, but I can summarize with: MAS is a much, much better solution than those you mentioned for X applications. To top it all off, I'm pretty sure it doesn't require X, and can be used for console apps as well. (mpg321, etc.)
I use ESD (Score:2)
Couldn't a
Re:I use ESD (Score:2)
I have a SBLive and my
Re:So, what do you use, then? (Score:2, Informative)
The only reason I can figure out that some people use sound servers is because their sound card doesn't support multiple opens of
Re:What's wrong with the old ones? (Score:4, Interesting)
Re:What's wrong with the old ones? (Score:4, Informative)
Remember: The first thing you should do when you log into KDE for the first time is go to the KDE sound server window and turn off the aRts server.
Re:What's wrong with the old ones? (Score:5, Informative)
Cue Flashback to 1992 (Score:2, Insightful)
Re:What's wrong with the old ones? (Score:2)
Re:What's wrong with the old ones? (Score:5, Informative)
This is life with aRts:
Open control panel. Tweak slider down. Launch MAME.
Open control panel. Tweak slider way up. Play mp3s while I work.
Open control panel. Tweak slider down. Launch Quake3.
Open control panel. Tweak slider up. Launch Xine. Live with audio and video being ~300ms out of sync because anything less causes horrible stutter.
The worst part is, if aRts were designed properly, this slider would be totally unnecessary. aRts also uses an insane amount of CPU time.
I'd like to see Gnome and KDE adopt Jack [sourceforge.net]. Jack works. MAS sounds interesting too. I look forward to seeing comparisons.
Re:What's wrong with the old ones? (Score:3, Informative)
When I did (finally) get it to work at all, the sound stuttered when playing any kind of audio. Upped the buffers, to no avail. This is on a 100mbit switched network.
Filed a bunch of bugs with the KDE/aRts folks, posted to the mailing lists and never got a satisfactory reply or fix.
Bring on MAS.
Re:What's wrong with the old ones? (Score:2)
Re:What's wrong with the old ones? (Score:2)
That's why it's an advantage. Using the same transport for graphics and sound reduces the chance that a user will need to care what the transport is.
Once an end user gets a remotely running application displayed, he doesn't want to worry about all his beeps and honks coming out of
Most people have enough trouble handling $DISPLAY, xhost+, and MIT-Magic-Cookie. Piling extra variables on top of that will make end-users throw up their hands.
"Oh, now I need to start esound client, esound server, esd-dsp when running programs, and then allow a separate UDP port through my firewall". "And now running X11-over-ssh, I have to create a separate VPN-tunnel for the audio data"
Sure, there are Linux distributions and smart sysadmins who prepare those things for you. But even they often mess up, and they can never plan ahead for all the flexibility an end-user may want. For instance, X-servers are available on Microsoft Windows. It'd be much easier to get a new version of one of those to understand "audio-over-X protocol" than to try running esoundd under cygwin!
Re:What's wrong with the old ones? (Score:5, Interesting)
Re:What's wrong with the old ones? (Score:2)
Re:What's wrong with the old ones? (Score:2)
I know what you mean. It's kinda weird to be running X apps displaying on a PC over one side of the room and hearing the bells coming out of a workstation on the other side.
Re:What's wrong with the old ones? (Score:2, Informative)
Password:
me@box1$ export SPEAKER="box2:0"
me@box1$ ogg123 cool_sounds.ogg
And hear it where I'm sitting, at box 2. Try THAt with esound or artsd.
Re: Incompatible design criteria (Score:2)
Five years ago, when esd, arts, etc. were in design, the majority of the (Linux) desktop environments that were in existence were limited to xanim and realplayer for a/v playback, which only played back a limited amount of the media available at the time. I figured allowing the capability to have ESD release control of the sound card for "incompatible" programs (quake, low latency audio mastering software, etc.) would be sufficient.
And judging by the fact that it's still available on most distributions today, that original feature set (hear messenging and wm beeps while playing mp3s) seems to hold up well. The problem is going to the next level beyond the external audio mixer, into the realm of synchronized A/V streams (much more prevalent today) and for that an integrated solution is necessary. NAS was the closest thing "back then", i.e. 5 years ago, and I couldn't get it working on Linux for more than two seconds, regardless of whose patches I applied. I assume none of the other mixing daemon authors could either...
NIH = Not Invented Here. (Score:4, Insightful)
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.
Re:NIH = Not Invented Here. (Score:2)
With your line of logic we should still be using the Bi-plane.
Frankly reality cannot be run like a business. There is no ONE answer to a problem. For every gain in efficiency by not persuing alternatives, you loose diversity and the chance to solve a novel problem.
In engineering you learn that all of the technology we take for granted it there because under the present set of circumstances, it worked out the best. This is exemplified in the MIC.
Now in the US, all of our planes use radar to track targets. We have always had an advantage producing digital computers, and packing them into smaller and smaller boxes. Now the Soviets did a lot of work with Infared imaging and analog electronics. Believe it or not, there are some nifty things they could manufacture that were miracles here.
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.
Re:NIH = Not Invented Here. (Score:2)
M-60 vs. M-249 would be a more appropriate comparison.
Re:NIH = Not Invented Here. (Score:3, Interesting)
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.
Re:NIH = Not Invented Here. (Score:2)
About time (Score:3, Interesting)
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).
Re:About time (Score:2)
You're kidding, right? The most stable and efficient window system servers around are X11-based. MS Windows and (in particular) OS X are flaky and sluggish in comparison.
Re:About time (Score:2)
I actually use X11, OS X, and Windows daily, so I have a basis for comparison. I've also done actual benchmarks. A good X11 server rocks in terms of performance and stability.
Re:About time (Score:2, Funny)
cool! (Score:2, Funny)
Wait a few days and you'll see RIAA trying to sue them :o)
Is it something like... (Score:3, Insightful)
Re:Is it something like... (Score:3, Informative)
SDL? [libsdl.org]
Re: (Score:2, Informative)
Re:Is it something like... (Score:5, Informative)
You should've read a little more about it. It's quite a bit more than a sound server, it's a graph-based media architecture, similar to DirectShow in Windows.
Re:Is it something like... (Score:2)
Re:Is it something like... (Score:2, Informative)
Re:Is it something like... (Score:2)
I'll have to see the bandwidth tests first. (Score:5, Insightful)
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.
Re:I'll have to see the bandwidth tests first. (Score:2)
For a remote display, X uses too much bandwith and has issues with firewalls and NAT, so people use vnc instead.
For a local display, X is too heavy.
Re:I'll have to see the bandwidth tests first. (Score:5, Interesting)
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)
use LBX, too (Score:2)
You can improve things further by using LBX (low-bandwidth X), by running "lbxproxy".
It does some X protocol aware compression. In addition, and perhaps more importantly, it caches some server information that applications commonly re-request over and over again unnecessarily.
Basically, all you need to do is:
$ lbxproxy &
$ export DISPLAY=:63
$ xterm&
Re:I'll have to see the bandwidth tests first. (Score:5, Insightful)
This will essentially be the same as streaming audio from the network. (You might be able to cache some sounds locally, for improvement, but for playing music or whatever that's probably not much of an option.) No, the modem users probably won't find this useful. But those of us with a fast connection to the other computer can benefit greatly.
Re:I'll have to see the bandwidth tests first. (Score:3, Informative)
Re:I'll have to see the bandwidth tests first. (Score:5, Informative)
"MAS enables low-latency Internet conferencing and telephony. Automatic bandwidth measurements and MAS's dynamically-switchable CODECs insure that the conference quality scales from 56K modems to T1 lines. "
"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. "
"MAS handles network-distributed media processing and intricate format configuration tasks. It continually measures system performance and adjusts its actions depending on the available system resources. The longer it runs, the better it knows your system."
Re:I'll have to see the bandwidth tests first. (Score:5, Informative)
Re:I'll have to see the bandwidth tests first. (Score:2)
Use VNC. Problem solved. I've frequently used VNC at high resolutions over slow links. It takes a bit of configuration to select the correct options (or perhaps not, realvnc is trying to do that part automatically now).
Re:I'll have to see the bandwidth tests first. (Score:2)
(Try running the old xterm over a modem link sometime, and compare it to something like gnome-terminal or konsole over that link. Even though the programs are essentially doing the exact same amount of screen manipulation, the old xterm is very fast and responsive even over a slow link. It doesn't feel much slower than a straight telnet or ssh would over the modem connection. In the olden days of X11, people still designed X applications not to be wasteful of bandwith. Today they don't really care anymore because bandwith is cheap.
Re:I'll have to see the bandwidth tests first. (Score:3, Informative)
Assumin a 16 bit sample rate, That 88,000 * 16 = 1.4 MB/sec. Worst case scenario, uncompressed. Everything in real life will be cutting some kind of corner, so this is the uber high-ball. (Drop your bir rate in half by going to 8 bit sampling, and again by going to 22Khz.)
That really isn't all that outrageous.
Now, if you are trying to make sound work over a modem, JUST USE THE PHONE INSTEAD.
Re:I'll have to see the bandwidth tests first. (Score:2)
These are all bits we're talking about here. 1.4Mb/s. Which is still a lot, but 8 times less than the number you quoted... about 176KB/s.
Re:I'll have to see the bandwidth tests first. (Score:2)
It can use RTP, or be embedded using X extentions so you can have remote sound where you have X (good for firewalls). You can even write another "net device" which is like a net abstraction layer - it's real flexible...
Re:I'll have to see the bandwidth tests first. (Score:2)
Re:I'll have to see the bandwidth tests first. (Score:2)
I'd really like to know just -what- you were running with XMMS that made it do 11mbps -- a graphical visulizer perhaps? I run XMMS across my 10mbps network all the time. I gave up on putting my XMMS skins on the server though, so I went with the "bandwidth hog" approach instead. I NFS mount my music from the server, play it locally on my laptop which pushes the sound BACK to the same server via EsoundD. It's not perfect, but it does work -- total usage is typically 2.5MBps for that route. Just doing XMMS from the server displayed on my laptop was -way- less than that too. I've got MRTG stats to show it too, but that's a few weeks old and the little bumps it made aren't really recognizable.
If you hit 11mbps you were trying to run a visualization tool over the network. Although, most of the vis. tools I see need local X to grab portions of the video card -- maybe some of the lesser intense tools don't though.
Just my thoughts -- me thinks that 11mbps total was coming from something besides X though. I've just never seen it.
Re:I'll have to see the bandwidth tests first. (Score:2)
No, it doesn't. The X11 protocol is the most efficient protocol for local and LAN usage around. It is, however, not a protocol designed for slow links (LBX is).
If you want to do a test try running the XMMS gui across the network via X11.
Then XMMS is a poorly designed X11 application. There are plenty of those around. In fact, there are very popular toolkits for X11 that are bandwidth hogs. But that's because the toolkits don't use X11 properly, not because there is anything wrong with X11. No protocol improvements can reduce bandwidth when an toolkit's or application's idea of a GUI is to ship lots of bouncing bitmaps around.
Re:I'll have to see the bandwidth tests first. (Score:2)
Easy: overall performance of a network transparent window system is not just determined by bandwidth usage. X11 deliberately was not optimized for bandwidth usage, it was optimized for overall performance, subject to the constraint of being able to run over a LAN. That is, X11 was optimized for how fast stuff actually renders on the screen and how much CPU it takes to do so (CPU is less of a concern these days, but it was a really big deal when X11 was designed and still matters on some X11 clients and servers).
So, yes, X11 uses more bandwidth than Citrix, but its overall performance over a LAN is better than that of Citrix. And that is still the case today.
If you want low bandwidth versions of X11, you can use LBX (low-bandwidth X) or dxpc (differential X protocol compression).
Re:I'll have to see the bandwidth tests first. (Score:2)
Remoting a video application is an idiotic basis for comparing the performance of network transparent graphics operations because it is so heavily dominated by the bitmaps that are being shipped around; it tells you nothing at all about how well the protocol is designed.
Also, Citrix doesn't even begin to address many of the issues that come up with network transparent window systems. Citrix is really more like VNC than a principled way of making applications network transparent. And between Citrix and VNC, VNC is by far the more impressive hack.
Re:I'll have to see the bandwidth tests first. (Score:2)
No, it can't. First of all, Citrix lacks many of the inter-client communication features of X11. But even just in terms of performance, Citrix uses less bandwidth out of the box, but it uses more CPU and has higher latency. On a LAN, that's a bad tradeoff.
So I guess X has an excuse for being a network hog.
As I keep saying: if you want low-bandwidth X, use the low-bandwidth version of the X protocol (LBX, DXPC).
Seeing as how VNC sucks ass going over my crappy Verizon(tm) DSL and using Word via Citrix over it is still very usable, I find that statement very hard to believe
I use VNC over DSL frequently and have used it even at ISDN speeds: it works reasonably well. But you have to choose the correct depth and compression. The short answer is: for dial-up, use TightVNC and reduce your bit depth.
Of course, X11 works fine even at dial-up speeds, in particular if you use the low-bandwidth versions.
Anybody who's used Metaframe for any length of time would laugh at that statement.
Windows users laugh at lots of things they don't comprehend.
The X Consortium's LBX = "Low Bandwidth X" (Score:2)
For people wanting to use X over low bandwidth connections, the X consortium (?) in their infinite wisdom invented LBX [paulandlesley.org] ("low bandwidth X").
Note that I don't know much about LBX except for the above, so if you used it and you think it sucks, it probably does. My point is that the X Consortium hasn't been ignoring bandwidth as you seem to suggest.
Re:I'll have to see the bandwidth tests first. (Score:2)
Re:I'll have to see the bandwidth tests first. (Score:2)
Sounds Good. Pun intended. (Score:2)
Perhaps this will kick some audio hardware makers into releasing some drivers for the Penguin.
I really wish I could run my Aardvark Q10 (awesome hardware) under something other than MS - they were working on Beos drivers before the death of Be. Those are probably sitting on a floppy in a file cabinet. :(
no mas! (Score:5, Funny)
Re:no mas! (Score:2, Troll)
Sure, it it has remote desktop capabilities to boot, but they're virtually impossible to configure and use.
To prove that a good, easy unix remote desktop is possible, look at VNC. You can have the same functionality with practically NO configuration (start the daemon, launch the client on the remote end, enter the IP address or domain name, and you're done.)
X11 has a lot of great concepts behind it. They're just implemented in a manner which makes them hard to use.
Either way, these problems should have been corrected 10 years ago. It would be easier to define a new protocol than fix X.
Re:no mas! (Score:2)
The battle cry of X and Christian haters world wide.
But does it go to 11 (Score:5, Funny)
Re:But does it go to 11 (Score:2, Funny)
apparently so!
devices/anx/mixer.c, line 96:
(100 seems to be max volume)
int16
dbvol_to_linear( int16 dbvol )
{
if ( lvol > 110 ) lvol = 110;
Re:But does it go to 11 (Score:3, Funny)
There's also a db scale, but... it's just not the same thing.
-Mike
Poor name choice (Score:3, Informative)
(http://www.motu.com/english/software/g
Perhaps they should have done a bit of name research.
What X needs more than a sound server: (Score:2)
Re:What X needs more than a sound server: (Score:4, Insightful)
Re:What X needs more than a sound server: (Score:2)
It's actually quite predictable what X11 applications do when transferring information via clipboards and selections. It's just a bit confusing because there are several different mechanisms, and different GUIs rely on different ones. If you run applications designed for different environments, things may seem confusing.
Stability at last! (Score:3, Funny)
Oh wait
Is the X Consortium relevant anymore? (Score:5, Interesting)
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.
Re:Is the X Consortium relevant anymore? (Score:2, Insightful)
And XPrint is pretty successful, if you count non-Linux platforms (where XFree86's Xprt XPrint server is horribly broken)
Re:Is the X Consortium relevant anymore? (Score:3, Insightful)
For a long time, x.org snubbed XFree86. It was finally accepted into the fold because the popularity of XFree86 had gone way above and beyond any other, and X.org had thus become quite irrelevent compared to Xfree86.
Re:Is the X Consortium relevant anymore? (Score:2)
Actually Xprint shipped with XFree86 was broken for a long time but recently was fixed up and works quite well. If you want great printing with Mozilla it's a must.
http://xprint.mozdev.org/ [mozdev.org]
and here's a good quick guide on it:
http://www.eskimo.com/~miallen/xprint [eskimo.com]
About time! (Score:3, Insightful)
Re:About time! (Score:2, Insightful)
If there are wonderful ideas implimented in existing projects, what's great about them all can be brought together and implimented into a new and accepted standard. Applications that exist to support them all can easily be modified by the community to support the new standard.
If there are 10 different sound servers out there in use, and they're consolidated down into just 1 or 2 using nothing but the best features, this can be a great thing. If one becomes standard and makes sound applications easier to bring to Unix, this is even better.
I personally have a lot of problems with X, but I still think something like this is a very good thing.
What about NAS? (Score:5, Informative)
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 [ed.ac.uk] - The Festival Speech Synthesis System.
- mpg123 [mpg123.de] - a command line MP3 player
- GAIM [marko.net] - a free AOL IM client
- OpenOffice (StarOffice) [openoffice.org] - the (now opensourced) StarOffice Suite has built-in NAS support for the Solaris and Linux Platforms.
- The Qt Library [trolltech.com] - from Trolltech [trolltech.com] supports NAS natively. You will need to pass the '-system-nas-sound' to './configure' before building.
- libSDL [libsdl.org] - SDL, the Simple DirectMedia Layer library, now has native NAS support thanks to Erik Inge Bols\x{00F8} [mailto]
- XAnim [pubnix.com] - the X Animation viewer
- XBoing [techrescue.org] - a blockout type X game
- XPilot [xpilot.org] - a multiplayer client/server space warfare game
- Xemacs [xemacs.org] - the best cross-plaform, cross-language IDE
- Alsaplayer [alsa-project.org] - A NAS Output plugin written by Erik Inge Bols\x{00F8} [mailto] is now supplied with the Alsaplayer distribution.
- X MultiMedia System (XMMS) [xmms.org]. A NAS Output plugin written by Willem Monsuwe [mailto] is available at ftp://ftp.stack.nl/pub/users/willem/ [stack.nl]
- Wine [winehq.org]. A NAS plugin written by Nicolas Escuder [mailto] is now available with the WINE distrubution.
Not a trollWhy not NAS, from a MAS developer (Score:5, Informative)
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
Thank you. (Score:2)
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.
Now THAT's hardcore. If only this existed two years ago...
Linux audio community has potentially better tool (Score:2, Interesting)
To this date the best audio server on Linux is JACK [sf.net], 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.
MAS is not a tool (Score:3, Insightful)
Likewise, we don't need another network audio codebase, we need a good network audio protocol. It looks like MAS provides that. As a bonus, you also get a reference implementation.
Woohoo! (Score:2)
x.org? (Score:2)
[calum@gatekeeper calum]$ whois b.org
[whois.crsnic.net]
Whois Server Version 1.3
Domain names in the
with many different competing registrars. Go to http://www.internic.net
for detailed information.
No match for "B.ORG".
>>> Last update of whois database: Mon, 3 Feb 2003 05:31:18 EST <<<
The Registry database contains ONLY
Registrars.
I want it!
Re:x.org? (Score:3, Informative)
Interesting, but is it Pro Audio? (Score:3, Interesting)
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 OT-Network Audio (Score:3, Interesting)
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.
The view of the MAS developers (Score:5, Informative)
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
"But What About Esound? Arts? NAS?" (Score:2)
I don't think I'd be stretching my luck to say that arts and NAS have similar limitations. I'll be interested to see if MAS is going to solve these problems, or if it's just another half-assed attempt.
3D audio rendering? (Score:3)
What, no cheap jokes yet??? (Score:2)
Wow, X-MAS is early this year. <grin>
So, maybe somewhere around X-MAS, Linux will have X-MAS builtin? <heh heh> <snarf>
So, is it Free as in "free from school/ work with X-MAS", or Free as in "a gift from Santa"? <heh> <yeah yeah> <snarf>
Virtual Environments - Network Monitors (Score:5, Interesting)
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).
Re:Virtual Environments - Network Monitors (Score:5, Insightful)
Re:Virtual Environments - Network Monitors (Score:2, Insightful)
Anyone who has ever dealt with a network down emergency will probably agree that in reality you would want your example sound samples reversed. You need the annoying stuff while everything is operating properly to help you stay awake, and the mellow "creek sounds" when your in all out panic mode ready to explode.
Re:Virtual Environments - Network Monitors (Score:2)
Cheers
Stor
Re:Virtual Environments - Network Monitors (Score:4, Interesting)
I always thought that would be wicked in a server room.
Re:Virtual Environments - Network Monitors (Score:2)
Other Applications (Score:3, Insightful)
1. CAVE environments. Anybody who's worked in an X11 CAVE environment knows that X can handle video cube arangements. Maybe not the most elegent way to run a cave, but it's do-able. X-sound-server can then provide 3D sound support to cave applications.
2. PACS environments (terminal services). Do you have a *nix based picture archiving and communication system (PACS)? For example: a hospital or library kiosk system. Now, your PACS is an audio environment as well.
3. Video Jockeying (VJ). If you're running a linux based VJ operation at a nightclub or dance hall, audio support is now available via X. You can now synchronize your video panels and speakers with the same daemon... Check out JMAX for more information...
4. Voice-over-IP kludge. As microphones are basically just speakers operating in reverse, theoretically, the X-sound-server should support microphones at some level... Hack your X11 system to support XVOIP!
Re:Better than esound (Score:2)
Gives a whole new meaning to XMAS tree scan
Re:Better than esound (Score:2)
Re:what about aRts (Score:2, Funny)
Cheers
Stor