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.

Comments

Huh

[houseofmore]

XMAS

Ahh.... how sweet. How gay.

Cool

[Nanite]

Any practical applications for this?

Sound+ Server

[Anonymous Coward]

With the sound and graphic capabilities, it sounds like a great start for a full blown MULTIMEDIA server

What's wrong with the old ones?

[martinde]

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?

Re:What's wrong with the old ones?

[Anonymous Coward]

I can tell you that esd sucks... I've looked at the code :) Arts, NSA, and rplay -- I agree. They should have based it on one of those existing servers.

Re:What's wrong with the old ones?

[akeru]

1. esound sucks, I mean, really
2. network transparent sound (ala X)
3. tightly coupled video and audio (check out their page for the latency requirements)
4. cooperates with the X server:
   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.)

Re:What's wrong with the old ones?

[optikSmoke]

arts = network-transparent, can be configured to send data over X, works with console apps, includes a plugin architecture for combining sound streams and applying funky effects and whatnot, and is already well-developed and stable. Also, it supports multiple underlying sound architectures (OSS, ALSA, and some for non-linux unices). Plus, it can play formats such as ogg and mp3, and can route normal oss apps to use it using artsdsp. Why the need to constantly be reinventing the wheel?

Re:What's wrong with the old ones?

[Anonymous Coward]

ESD is just NAS warmed over. NAS is old and terrible, basically.

ArTS is the only 'sound daemon' I've encountered that is actually decent. The rest are junk, including HPUX's proprietary Asound library.

Re:What's wrong with the old ones?

[DunbarTheInept]

For one thing, I've wanted for a long time the convenience of being able, in one setting, to describe the remote-relationship for all media. I don't want to have to say, "send my $DISPLAY to this host, and then here's a command-line arg to do the same thing for this one music file I want to play." I want to be able to say, "Send all my media to $DISPLAY, both visual and audio" and then be able to have all X programs pick up on that.

Re:What's wrong with the old ones?

[VistaBoy]

I have much to bitch about aRts...Quake 3 for Linux crashes at startup with it on, and artsdsp doesn't work very well with Quake 3. Not only do you have to do "artsdsp -m quake3", but when you fire a shot, you see the shot, and about two seconds later you hear it. To alleviate that little problem, you have to turn down the buffer that the aRts server has. However, in doing that, you make the sound stutter like a mofo. OSS works properly with Quake3, but aRts is a stumbling block.

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?

[Penguin Follower]

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.

If I do that, what is going to allow me to have sound from my X apps? You have to have a sound server, correct?

I use KDE, and experience the sound lag you talk about. It drives me up the proverbial wall. As I mentioned in an earlier post, I killed arts and tried ESD, with not much of a difference. It was only marginally better.

Re:What's wrong with the old ones?

[eviltypeguy]

You only need the sound server if you want "gee neato" sound effects from KDE or Gnome. I'm not aware of any game or program personally that specifically requires one of these sound servers to be active. XMMS for example can output directly to /dev/dsp using the OSS driver.

Re:What's wrong with the old ones?

[EvilTwinSkippy]

I can say from experience though, that is not the friendliest system in the world to set up. Crap, if I have a Wish shell that plays a music file I want to hear it on the remote terminal without having to fart around with special server software.

Re:What's wrong with the old ones?

[dozer]

aRts is every bit as bad as esd. That performance/latency slider is impossible to set such that sound has decent latency and doesn't stutter.

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. Jack works. MAS sounds interesting too. I look forward to seeing comparisons.

Re:What's wrong with the old ones?

[bicho]

... do "artsdsp -m quake3", but when you fire a shot, you see the shot, and about two seconds later you hear it. ...

Thats the sound's speed man!

Re:What's wrong with the old ones?

[Rysc]

me@box2$ ssh box1
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:What's wrong with the old ones?

[MikeFM]

Finally, maybe we can end every half assed project having it's own sound server. Honestly to keep sound working between KDE, Gnome, and other apps I've constantly flicking on and off various sound servers. Sure apps can autodetect them and deal with them but some apps don't bother and there is always one app you use that won't work with the sound server all the other apps work with. I'll be a happy camper when we have a good standard that works with everything. Maybe MAS is that standard. :)

Re:What's wrong with the old ones?

[Anonymous Coward]

esd was written by raster and ricdude, what do you expect?

Re:What's wrong with the old ones?

[Anonymous Coward]

Network transparency works for both. Good job, retard.

Re:What's wrong with the old ones?

[Phexro]

Have you ever tried to use aRts' network transparancy? It's a sick joke. Neraly impossible to get functioning correctly, impossible to get working acceptably, and lacking any useful documentation or examples. I tried setting it up so I could have network audio on a (net-booted, diskless, Debian) X-terminal. I had to install aRtsd on the X-terminal (no problem), but ran in to problems because the aRts server must run as the same user that's logged in to the server. Small problem, since I use LDAP, but this destroyed my dreams of zero-administration on the X-Terminal. Oh, and aRtsd needs to be spawned on the X-Terminal at login time, and it doesn't die when you log out, so you need to manually kill off all the artsd processes, or restart the terminal.

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?

[i_am_nitrogen]

Jack seems like a really cool idea. Once I finally got it to work though, the sound was distorted. I mean, really really bad. It sounded like it was being quantized to 4-bit precision, but separately for each major frequency band.

Any idea what could fix that?

Re:What's wrong with the old ones?

[BESTouff]

IIRC esound does just that

Re:What's wrong with the old ones?

[gid]

I'd love to see both arts and esd die a horrible death.

Fact is that I've never run a sound server for more than a few minutes, it's the first thing I disable. I never really got the point, if you have a half ass sound card and decent drivers, then multiple apps should be able to use the sound card and once and it should do hardware mixing, screw that software mixing stuff.

Re:What's wrong with the old ones?

[Anonymous Coward]

"aRts is every bit as bad as esd. That performance/latency slider is impossible to set such that sound has decent latency and doesn't stutter."

Did you try to run it with maximum priority (you need to setuid for that)?

Re:What's wrong with the old ones?

[Grizzlysmit]

I'd like to see Gnome and KDE adopt Jack [sourceforge.net]. Jack works. MAS sounds interesting too. I look forward to seeing comparisons.

Does it have a sister called Jill. :-)

Re:What's wrong with the old ones?

[psamuels]

1. esound sucks, I mean, really

OK. I haven't looked at the code, but I've certainly heard that more than once. That doesn't rule out rplay, NAS, aRts, or other miscellanea like the HP-UX sound server, which (being based on DCE) is truly perverse for other reasons entirely.

2. network transparent sound (ala X)

Uh, that would be all of the above. Actually I'm not sure about ESD, but at least the others are all network-transparent.

3. tightly coupled video and audio (check out their page for the latency requirements)

Yes, that's the one reason I buy, aside from the obvious NIH.

4. cooperates with the X server: can send audio data over a number of different transports, including CORE X

Yes, but how is this an advantage? The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care? The only reason they should is to get past / tunnel through a firewall, which can certainly be done other ways. NAS in particular makes this fairly straightforward.

To top it all off, I'm pretty sure it doesn't require X, and can be used for console apps as well.

So can any of these others. In practice, console apps often just open the local audio device because they assume you are sitting in front of the local console. But if a case could be made that any given user is likely to be at a remote terminal that happens to support NAS or one of the others but doesn't support X, console apps could adapt. (Indeed, libao-based apps, like ogg123, already have.)

Re:What's wrong with the old ones?

[sql*kitten]

I want to be able to say, "Send all my media to $DISPLAY, both visual and audio" and then be able to have all X programs pick up on that.

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?

[lmfr]

network-transparent? Have you ever tried to put a X server with a sound card that connects to a remote XDM server to work? I had to do the following:

• create .mcoprc to tell remote arts to use X11 communication. That's because each new artsd has different connection values, even with the same port, host, etc. And do a rsync of /tmp/mcop to every user and host isn't acceptable.
• stop arts from resetting the configuration file to defaults: chmod -w .mcoprc
• create a /etc/X0.hosts so localhost can connect locally
• create a script that kills any local artsd, launchs the X server, and afterwards runs the new artsd
• change inittab to run that script instead of X -broadcast

Re:What's wrong with the old ones?

[Anonymous Coward]

No, it doesn't. Do remote X and see how well esound works. You'd have to do more environment variable tweaking, and even then, the sound quality will be shitty.

Re:What's wrong with the old ones?

[Anonymous Coward]

I'm from Bethesda, and I thought this too. Yay!

Re:What's wrong with the old ones?

[Minna Kirai]

The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care?

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 /dev/dsp in the server room. But that's what'll happen until he figures out how to configure a completely separate transport mechanism to tell the audio where he's sitting.

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?

[Minna Kirai]

It would be additionally great if other aspects of your remote terminal could be reported to an application server in the same variable as well.

Stuff like: joysticks, cdroms, writable local storage (under strict permissions set by the Xserver config), even local USB devices.

Because you know, if thin-clients based on *nix and X11 ever become popular, users will want to save files to a floppydisk in front of them without navigating down /mnt/samba/what_hostname_am_i_sitting_at_again?

Of course, developing this would be much harder than building audio capabilities- terrible OS incompatibilities, as well as conflicting with existing X abilities.

To reach this goal, you'd nearly have to create a new application-service system, with X11 as just one component.

Re:What's wrong with the old ones?

[ChaoticLimbs]

Is that why BZFlag doesn't have sound in KDE on my Mandrake box but ICEWM has sound? In KDE and Gnome, sound shows as unavailable.

Re:What's wrong with the old ones?

[Bert64]

The fact that theres so many incompatible soundservers, and programs can work with either a soundserver, or native os support, and most soundservers block your native os sound support..
In addition, soundservers increase latency and processor usage... its just another hoop to jump through.
With a standardised soundserver that`s part of the official X11 specs, hopefully support will level out.. and other servers will adopt their interfaces to comply with the standards... Personally i believe a soundserver should offer an interface compatible with that provided by the native os, and should ONLY be used for network sounds.. playing local sounds through an additional process is just a waste of resources unless that process has some value-add, such as effects generation.... still, the choice should be there to use the sound hardware directly for those of us who dont want fancy reverb effects etc.

Re:What's wrong with the old ones?

[Anonymous Coward]

Yes. Run it with 'artsdsp' or 'esddsp' as appropriate to make it look like it's getting /dev/dsp but actually getting a port to the sound server via a LD_PRELOAD hook.

I'm frankly amazed so many people don't understand this.

Better than esound

[Fastball]

I'm all for this. Anybody who's dealt with esound knows that XMAS or anything else would be an improvement.

Re:Better than esound

[einhverfr]

I'm all for this. Anybody who's dealt with esound knows that XMAS or anything else would be an improvement.

Gives a whole new meaning to XMAS tree scan ;)

Re:Better than esound

[EvilTwinSkippy]

Hey why is my terminal suddenly playing Festivus music?

About time

[InterruptDescriptorT]

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).

Re:About time

[evilad]

/me is vastly amused by Moderator failure to catch your double usage of the word "sound".

Re:About time

[gurensan]

Did you read even the website? Why is this moderated a 5, when you're talking about bad colormaps crashing X in a discussion about a sound server for it?

>>quoth you:

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.

>>

What?

Re:About time

[Anonymous Coward]

You're retarded.

Re:About time

[damiam]

A sound server for X. Think about it.

Re:About time

[gurensan]

Oh jeez. That explains the high moderation. They should have said 'Audio' server - woulda saved me embarassment!

Re:About time

[g4dget]

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).

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

[SewersOfRivendell]

/me does a spit-take.

I'd assume this is a troll, but maybe it's just youthful exuberance? Please.

X is so flaky you could serve it for breakfast.

X is so inefficient that GM is considering using it for an engine in the next Chevy Malibu.

X is so unstable that Ford is considering using it as tires on the next Explorer.

Re:About time

[g4dget]

I'd assume this is a troll, but maybe it's just youthful exuberance? Please.

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.

what about aRts

[Anonymous Coward]

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?

Re:what about aRts

[stor]

Regardless it gives us a new thing to fight about, which is obviously A Good Thing.

Cheers
Stor

cool!

[Domingos Neto]

Now this is a ground breaking technology: now I can listen to my mp3 collection even when I'm accessing my workstation remotely!

Wait a few days and you'll see RIAA trying to sue them :o)

Re:cool!

[Anonymous Coward]

WindowsXP does this, already, with Remote Desktop.

Go ahead, mod me -1 Troll.

Re:cool!

[Doug Neal]

Whatever. Unix had remote display and remote audio years before Microsoft pretended to have invented it.

Is it something like...

[cronot]

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)

Re:Is it something like...

[FooBarWidget]

"but I mean something more higher level - like DirectSound"

SDL?

Re:Is it something like...

[ikewillis]

"ESound? Asd? ARTs? It seems a little different in concept"

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...

[1010011010]

What's the overlap with GStreamer? Does MAS mean we don't need GStreamer?

Re:Is it something like...

[gurensan]

.. OpenAL, only network transparent?

Hmm.... Can an OpenAL scene be transmitted over a network like an OpenGL scene can (theoretically)?

Re:Is it something like...

[stem]

No, you can still use GStreamer. We're working with the GStreamer guys to get the integration right.

Re:Is it something like...

[IamTheRealMike]

If they are both graph based streaming systems though, how exactly does that work? Do you have GST Elements that fork the audio off into MAS, where it joins up with another graph? I think GStreamer has some great potential but obviously it's an in process thing, so an audio server to go with it would be great, but looking at the website it seems there is a lot of feature overlap.

I'll have to see the bandwidth tests first.

[FreeLinux]

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.

Re:I'll have to see the bandwidth tests first.

[javilon]

Completely agree,

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.

[kondrag]

Did you try it without the spectrum analyzer and scrolling text? I would imagine that XMMS is very bandwidth intensive because of its ultra-dynamic display.

Re:I'll have to see the bandwidth tests first.

[akeru]

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)

Re:I'll have to see the bandwidth tests first.

[Anonymous Coward]

X11 needs a new protocol.

Actually, I think we need a new user interface that doesn't include X11.

Face it: it's time has come.

People keep on piling crap on top of X11 because that's what is there. We need a new foundation to start things on.

And I'm not talking about Berlin.

I'm more interested in (e.g.) QT/KDE retargeted for direct frame buffer manipulation.

Re:I'll have to see the bandwidth tests first.

[aardvarkjoe]

Your problem is that you're trying to use a program that relies on eye-candy over the network. (At least, I think that's the idea. I can't imagine any other reason for the incredibly bizarre interface of XMMS.) Of course it's going to be slow without a fast link. How is a "new protocol" going to help?

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.

[xeniten]

It sounds like ( pun intended ) that they have taken bandwidth into account. There are a number of references to bandwidth performance on the MAS site.

"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.

[Daengbo]

The last time I did it, XMMS was using 11 megabits per second.
I doubt it. My little workstation uses XMMS all the time with Gimp going and xmms playing through the esound plugin, and the station right now is consuming about 200k for the Coyote Ugly soundtrack. I can (and have) run 25 clients with xmms over a 100Mb network. full screen visualization. Whatever you're doing, I doubt that it's taking 11Mb. I have never pushed a single station over 1. But this one goes to 11...
I would, however, like to see this if only because so many apps are only aware of one or two sound daemons (some only dsp) and this might make network sound easier to set up and more consistent across applications, which is the only real problem that I now run into. Flash, for instance, doesn't seem to like me for using esd.

Re:I'll have to see the bandwidth tests first.

[Anonymous Coward]

Since it relies on X11 I suspect the bandwidth requirements are going to be really high.

"It processes graphic information locally, alleviating the need for network transmission of uncompressed graphical content."

Re:I'll have to see the bandwidth tests first.

[doodzed]

Try doing it through an ssh compressed tunnel.
"ssh -C me@myhost.edu"
It runs a lot faster. It works over dialup( saved me whan I was dialing via 28.8 in mid 90s. If you are using X to windows, putt and verious other ssh clients will create the tunnnel and compress it.

Re:I'll have to see the bandwidth tests first.

[eviltypeguy]

Actually, MAS may integrate with X11, but it doesn't use the X11 protocol, it uses the "RTP" (Real Time Protocl RFC 1889, January 1996) for all communications. Except for multicast mode or in multi-participant mode. RTP is obviously very efficient for this type of data payload...

Re:I'll have to see the bandwidth tests first.

[evilviper]

X11 over the network is a bandwidth hog

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.

[On Lawn]

X11 over the network is a bandwidth hog, that's all there is to it.

I'll beg to differ, but I admit I'm not sure what the slowness from X comes from. We spent a month or so trying to figure it out once, just becuase we didn't like exceed and didn't want to have to use it. In the long and short of it, bandwidth was ruled out pretty quickly.

Let me explain the background here. So our employees can VPN, we run many apps over X. Its snappier then VNC for the layout people, but has some lag time loading programs, and responding to clicks.

I think a lot of it is client based. Exceed worked great, even on 56k connections. The XFree client (both on windows and Linux) didn't, and hooking up larger and larger pipes didn't seem to effect it. Truth is we never measured that great a bandwidth usage from any of our tests.

I'd be interested in seeing any data you have on what made X so slow, especially if you think it is bandwidth. We even ran the X compression server, and that sped things up a bit, but not reliably.

----------------------
OnRoad: Posting automotive articles is automatic, democratic and fantastic.

Re:I'll have to see the bandwidth tests first.

[netsharc]

What about DirectFB? They have their patched version of GTK+ that will allow it to work with their framebuffer library.. looks neat, I wonder if Gnome can run on it. Someone care to explain to me how they all (Gnome, GTK+, the "screen-device") work together? AFAIK Gnome talks to GTK, and GTK talks to X, or in this case DirectFB. I guess it would be neat, only 58 days before my exams are behind me and I can get to play with these. :)

Re:I'll have to see the bandwidth tests first.

[DunbarTheInept]

It's not X itself that is to blame. It's many of the applications written for it. All too often people get lazy and forget that calls to the X server shouldn't be needlessly repeated. If information returned by an X call isn't going to change, then get the info just once and remember it in a variable - don't repeat the same call over and over in a complex mathematical expression, for example. X *can* be efficient, but it doesn't force the applications to be effiecient, so many of them turned out not to be.
(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.

[EvilTwinSkippy]

Okay, CD quality sound in stereo 44Khz * 2 = 88Khz.

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.

[DunbarTheInept]

He was referring to the bandwith used by running XMMS's X gui remotely, not the bandwith used by XMMS's audio data.

Re:I'll have to see the bandwidth tests first.

[obi]

You can choose:

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.

[iabervon]

The X protocol gets slow for some applications because the applications are generating too many requests, because they're doing the rendering essentially on the client side and sending it in little updates across the network to the server. That's why MAS "processes graphic information locally (i.e., on the X server)", so that you send the compressed synchronized sound and video to the server, which then puts it on the screen without sending it uncompressed over the network, like xmms is doing with its UI.

Re:I'll have to see the bandwidth tests first.

[Daengbo]

So was I. I am running everything off of a diskless xterm with networked sound. Give me some credit.

Re:I'll have to see the bandwidth tests first.

[dontkillme]

Tunneling X11 through ssh and using the -o CompressionLevel=9 argument helps decrease bandwidth requirements dramatically, albeit with the cost of slightly higher application response latency.

Re:I'll have to see the bandwidth tests first.

[andrewski]

This is the reason that the low bandwidth x proxy (man lbxp) is included by default with X.

Re:I'll have to see the bandwidth tests first.

[Dynedain]

If you have ever seen WinAmp, then you would understand the "incredibly bizzarde interface of XMMS". XMMS is designed to act like WinAmp, and use the thousands and thousands of WinAmp skins available.

Re:I'll have to see the bandwidth tests first.

[toomim]

The *only* problems I have encountered involved XEmacs doing silly things with the cut-buffer and pausing momentarily.

You can fix this by putting (setq x-selection-strict-motif-ownership nil) in your .xemacs/init.el file. This disables a poor implementation of the motif clipboard protocol that uses up a few megs of bandwidth per cut/paste operation.

If this is the *only* problem you're having with X connections, it'll soon be absolutely perfect!

Re:I'll have to see the bandwidth tests first.

[damiam]

I could stream a full uncompressed video that entire section of the XMMS window for less than 11 mbits/sec. X is supposed to be a lot more efficient than that (I guess xmms's themed interface doesn't help, though).

Re:I'll have to see the bandwidth tests first.

[pi_rules]

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.

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.

[g4dget]

X11 needs a new protocol.

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.

[Anonymous Coward]

No, it doesn't. The X11 protocol is the most efficient protocol for local and LAN usage around.

When Citrix Metaframe uses 1/10th the bandwidth of X11, the onus is completely on you to justify that statement.

Maybe you meant "X11 was the most efficent protocol for LAN usage and extremely slow, functionally retarded hosts back in 1989 when it was invented."

Re:I'll have to see the bandwidth tests first.

[Anonymous Coward]

Would that be Citrix with the same programs, or with different programs?

There are lots of things that an application developer needs to be careful about with the X protocol, especially when writing something like XMMS. X is able to store the bitmaps server-side, so that refreshing a window like XMMS is only a couple of coordinates = almost no bandwith necessary. Or it can be done with the bitmaps client-side, sending each pixel over the line every time anything is updated = huge bandwidth hog.

I'll admit that windows (with or without citrix) has an advantage here, by making it so complex to create a bitmap, that programmers will only want to do that once, and keep reusing the handle they get the first time around.

Re:I'll have to see the bandwidth tests first.

[Anonymous Coward]

I've seen both and I still don't get it. Why on earth can't they use standard widgets?!

Re:I'll have to see the bandwidth tests first.

[g4dget]

When Citrix Metaframe uses 1/10th the bandwidth of X11, the onus is completely on you to justify that statement.

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.

[Major Woody]

> 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.

Umm ... no. It is not. You can even watch a video in Media Player, with sound, over Citrix. If anything, they're about equal in performance. Not bad for something which wasn't designed for network transparency in the first place.

But when you consider that Citrix uses much less bandwidth than X11, it really puts plain vanilla X11 in perspective.

Re:I'll have to see the bandwidth tests first.

[g4dget]

Umm ... no. It is not. You can even watch a video in Media Player, with sound, over Citrix. If anything, they're about equal in performance.

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.

[Major Woody]

> 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;

I used that example because you can do the same thing with X11 also (tho, minus the sound which is handled by something else if you wanna stick with X), but Citrix does it with less bandwidth. In fact, Citrix does everything you'd want to accomplish with X but with less bandwidth.

> it tells you nothing at
> all about how well the protocol is designed.

X may be a better designed protocol (I don't know because I don't know the details of the ICA protocol and since you are clearly biased I would take your word with several grains of salt), but Citrix can do what X can using less resources so who cares. Granted, X wasn't designed with low bandwidth usage in mind and ICA was. So I guess X has an excuse for being a network hog.

> And between Citrix and VNC, VNC is by far the
> more impressive hack.

More biased bullshit. 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. Even when using TightVNC. So don't give me that shit that "VNC is a more impressive hack" because it is clearly not. Anybody who's used Metaframe for any length of time would laugh at that statement.

Re:I'll have to see the bandwidth tests first.

[g4dget]

but Citrix can do what X can using less resources so who cares

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.

Re:I'll have to see the bandwidth tests first.

[dietz]

Assumin a 16 bit sample rate, That 88,000 * 16 = 1.4 MB/sec.

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.

[DunbarTheInept]

I am running everything off of a diskless xterm with networked sound. Give me some credit.

Then you should have said so, since that's not a typical setup these days, and is highly relevant to your point. Instead you talked about bandwith of the sound and not the gui.

Re:I'll have to see the bandwidth tests first.

[jimfulton]

Actually, you could watch video (with sound, using NAS :-) from an NT box connecting to an X display long before ICA ever had audio, or the (relatively) recent optimizations for turning off compression over LANs. All you needed was WinCenter, a package NCD developed to layer on top of Citrix's Multi-Win NT kernel (this was pre-Terminal Server).

It blew the pants off of every other NT remoting solution and led to a competition that ultimately made all of the products better. ICA got faster on LANs, WinCenter added an extension that got bandwidth consumption down to almost ICA-like levels (the NT remoting traffic had very specific patterns that could be optimized more easily than was the case for general X traffic in LBX).

WinCenter even did some rudimentary synchronization of NAS audio with X graphics. And, it supported audio input as well as output. And MIDI (Keith got inspired one weekend :-).

Re:I'll have to see the bandwidth tests first.

[Dynedain]

because standard widgets are boooooooring...which joe user doesn't want

i like having skins for my media player....and i think most other people do too

hell, even windows media player and quicktime have both dropped 'standard widgets'.

Sounds Good. Pun intended.

[teamhasnoi]

Really swell - one of the things that has held me back from linux is the lack of hardware/software high quality audio. Could we see Protools for Linux(TM) (hmm? OS X not *that* different?)

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. :(

Re:Sounds Good. Pun intended.

[Anonymous Coward]

http://www.rme-sound.com/
http://jackit.sf.net/
http://ardour.sf.net/
http://www.eca.cx/
http:// www.alsa-project.org/

Re:Sounds Good. Pun intended.

[Anonymous Coward]

make that first one http://www.rme-audio.com ...

no mas!

[prockcore]

Great, all the people who think X is too bloated as it is will now be crying "No mas!"

Re:no mas!

[moosesocks]

X isn't bloated. It's unnecessarily complicated.

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!

[FroMan]

Great, all the people who think X is too bloated as it is will now be crying "No Xmas!"

The battle cry of X and Christian haters world wide.

Christmas?

[PincheGab]

Hey, is it just me, or has anyone else noticed: X-MAS = Christmas?

Have to ask, as always

[Anonymous Coward]

Does it play Ogg Vorbis files?

Yawn.

Thanks X.org

[Chexsum]

This will save us from having to configure each programs sound device. =) /me waves @ dsp/esd/arts

Virtual Environments - Network Monitors

[VoidEngineer]

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).

Re:Virtual Environments - Network Monitors

[Greedo]

You're talking about Peep, right?

Re:Virtual Environments - Network Monitors

[itallushrt]

Sorry that is off-topic, but after working in a large NOC for several years I think I can speak from experience by saying that the last thing I want to hear when my network starts going haywire is a bunch of loud ass crows or some elephant blathering about who knows what.

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

[stor]

What's wrong with logfiles?

Cheers
Stor

Re:Virtual Environments - Network Monitors

[ryanvm]

I'm surely getting some of the details wrong, but I believe that one of the big tech universities had something like this. It was a big cable that extended from the floor to the ceiling, and it moved according to the amount of network congestion being experienced. So if utilization was down around 5 or 10 percent it would be gently wiggling, but as utilization increased the degree to which it would thrash and flail increased too.

I always thought that would be wicked in a server room.

Re:Virtual Environments - Network Monitors

[Chicane-UK]

It wouldn't be too funny trying to get in there if network congestion was at 100% - could have someones eye out with that :)

Re:Virtual Environments - Network Monitors

[Anonymous Coward]

MIT Media Lab. They had the soothing sounds and colors and stuff too. Pretty cool.

does it run on BSD?

[Anonymous Coward]

All my computers run BSD and X10 itself ran on Ultrix, which was BSD-based. So my most important question is does MAS run on FreeBSD?

Re:does it run on BSD?

[Anonymous Coward]

nope

MAS. The other MAS.

[lastberserker]

Pardon me, but you need to get your TLAs
corrected - MAS stands for Multi-Agent System ;-P

Re:MAS. The other MAS.

[Anonymous Coward]

Worse than this. MAS is (iirc) the name for the sound plugin format of ProTools. I wonder if Digidesign is going to complain about this. In general trademark conflicts are only tolerated if they don't get into each other's market.

hope this doesnt suck like X-font server

[soorma_bhopali]

I would not like fuck around with anti-aliasing/recompiling/enabling_byte_code_rende ring with sound files !!

But does it go to 11

[niall2]

Thats the real question...

Re:But does it go to 11

[Anonymous Coward]

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; /* clamp at 110. It's one louder */ .....

Re:But does it go to 11

[stem]

The official reason is that we're going to restrict the volume settings to 0-100 for non-privileged users, and allow privileged users to set the volume up to 110. This way, privileged users can always punch through the mix with something that's a little bit louder. How much louder, you ask? One louder.

There's also a db scale, but... it's just not the same thing.

-Mike

Sounds Good But...

[jodo]

What I want to know is how does one obtain a single letter domain. i.e. x ???

Re:Sounds Good But...

[lewp]

1) Get a time machine.
2) Go back 20+ years.
3) ???
4) Profit.

Re:Sounds Good But...

[Skater]

The easiest way may be to invent a time machine...

--RJ

Re:Sounds Good But...

[Anonymous Coward]

Perhaps they can use www.xmas.org ?

Poor name choice

[soupdevil]

There is already a MAS associated with audio -- MOTU Audio System plugins.
(http://www.motu.com/english/software/gl obal/index .html)

Perhaps they should have done a bit of name research.

Re:Poor name choice

[Anonymous Coward]

Okay, I'll grant you that point. Guess they'll just have to start calling it "X-MAS"... oh wait... my bad.

Re:Poor name choice

[stem]

In fact, we were using the term MAS(TM) in public before Mark of the Unicorn. And, if you look, they have no trademark, registered or otherwise on "MAS".

Mike Andrews
Lead Developer, MAS Team

Re:Poor name choice

[soupdevil]

Interesting. At what point did you start using the name MAS in public?

I use ESD

[SHEENmaster]

because it keeps /dev/dsp from fucking up, allows simultaneous feeds, and doesn't give me crap.

Couldn't a /dev/dsp replacement be made with the same features?

Re:I use ESD

[Anonymous Coward]

Uh, no.

Re:I use ESD

[eviltypeguy]

Good sound cards with good drivers allow the same thing. For example, I believe my Audigy allows for up to 63 or 64 simultaneous opens of /dev/dsp.

I can run a game and XMMS at the same time just fine without ESD or Arts running.

I don't need ESD :)

Re:I use ESD

[Nothinman]

Depends on your sound card driver.

I have a SBLive and my /dev/dsp allows multiple open()s and doesn't give me any crap.

What X needs more than a sound server:

[pheph]

A clipboard server! Has anyone else noticed the really unpredictable behavior of the clipboard in X applications?

Re:What X needs more than a sound server:

[diamondc]

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.

Re:What X needs more than a sound server:

[illogical_simby]

I agree! But what we need even *more* than that is a server to detect when my kettle is boiling, and another that notifies me (via email) when my alcohol stash needs refilling.

Re:What X needs more than a sound server:

[g4dget]

It already exists: it's called "xclipboard". It's just an X11 application. You can also use a reasonable X11 text editor to keep and translate selections.

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!

[YetAnotherName]

A sound, solid server will certainly help with all sorts of stability problems I've experienced with X over the years.

Oh wait ... you meant sound as in audio? Oh, nevermind.

Is the X Consortium relevant anymore?

[GGardner]

Is the X Consortium (err, the Open Group), even relevant anymore? Substantially all the good work for X is done under the auspices of the XFree86 folks, or the higher level toolkits (GTK, KDE, etc.).

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?

[akeru]

XFree86 is the "Official" X.Org references implementation, if that answers your question.

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?

[Anonymous Coward]

> XFree86 is the "Official" X.Org references implementation, if that answers your question.

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?

[KidSock]

Their XPrint work is just as successful.

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/

and here's a good quick guide on it:

http://www.eskimo.com/~miallen/xprint

Please God No...

[Anonymous Coward]

I don't want a bloated with an ancient feel for a sound server.

Linux needs to be saved from X and not to use it even more.

God no.

NIH = Not Invented Here.

[Ungrounded Lightning]

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.

Re:NIH = Not Invented Here.

[EvilTwinSkippy]

So?

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.

[jedidiah]

That might be because the M-16 was always meant to be a lowend sniping rifle and not a Tommy Gun. Devices tend to reflect their design goals. The US always had other weapons (and associated specialists) for when "rate of fire" was the objective.

M-60 vs. M-249 would be a more appropriate comparison.

Re:NIH = Not Invented Here.

[Ungrounded Lightning]

With your line of logic we should still be using the Bi-plane.

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 .222 can supply the whole war for several months, which is exactly what happened, JUST as they were going into general service.

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.

[EvilTwinSkippy]

I'm not worthy.

About time!

[Kickasso]

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.

Re:About time!

[Jace of Fuse!]

I know a lot of people get upset thinking that a good standard coming along will make obsolete similar work done by others, but is this not what's good about open source?

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.

Re:About time!

[Anonymous Coward]

I totally agree. Linux cannot even standardize a common desktop - think about what a mess it would be without even X to base the desktops on..

Shiman

[sQuEeDeN]

Heh. I did a double take just then, when I thought I read Sharman associates instead of Shiman-- Well, p2p is just like Sound servers, no? ^_^

What about NAS?

[axxackall]

Why not use NAS, The Network Audio System?

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 troll

Re:What about NAS?

[jimfulton]

When we designed NAS, we intended it to be a (relatively) simple, but flexible, framework that allowed components to be wired together in many different ways and new things added as they were needed. Bonus points go to anybody who recognizes certain similarities (good or bad :-) between it and the X Image Extension...

However, during NAS's early life, some of the more interesting multimedia-enabling technologies such as RTP, XSYNC, and others weren't widely available. So, we had to move on before we could add things like non-TCP streaming audio (essentially extension device objects that would send/receive over a separate datagram socket instead of the TCP-based control socket) and integration with the X Synchronization extension or other video playback technologies.

AudioFile had better support for managing time, but it lacked a lot of flexibility and automatic conversion that NAS provided.

In the end, some cool things were done with both NAS and AudioFile, but in reality they both were missing key design elements that really need to be there. Without a strong organization pushing them forward, they weren't going to be practical in the long run.

Leon has historically done interesting stuff, so I would feel pretty confident that his team did their homework.

Jim Fulton
former NAS protocol weanie, a looooong time ago

Linux audio community has potentially better tool

[Anonymous Coward]

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.

So, what do you use, then?

[Penguin Follower]

So, if you don't have artsd or esd, what is taking care of your sound? I would like to know, because I get less than acceptible results at the moment. I have an onboard ac '97 codec (via chipset) that works fine in windows, blows chunks on Linux, because Arts "overloads" or something like that (I can't remember the error message exactly.) Plus, there is a huge lag in sound on games. Example, in gltron, the sound is about 2 seconds behind. I tried switching to ESD, and although it worked better than artsd, there is still some lag at times. Same goes for Tux racer. Meanwhile, the graphics card never skips a beat.

Re:So, what do you use, then?

[eviltypeguy]

XMMS uses /dev/dsp with OSS output. And my games uses OSS with /dev/dsp as well. So no sound server necessary. Sure I don't get network transparency, but I don't need it. I bet you'd find that if you disabled both ESD and Arts that many of your games would still have sound, especially if they're using SDL.

The only reason I can figure out that some people use sound servers is because their sound card doesn't support multiple opens of /dev/dsp with OSS, their applications don't support OSS directly (so instead they use the sound server) or they need network transparency.

Re:So, what do you use, then?

[Anonymous Coward]

I'm pretty sure that the SB Live & Audigy cards do their multiple source mixing in hardware. I've never been overly impressed with esd, arts, etc. I'd say it's well worth it to get a card that does hardware mixing, and let your CPU concentrate on something else.

I've also wondered why the dsp driver hasn't been made to do software mixing on cards that can't do it in hardware. Maybe it's something that would have to be done per sound card chipset? I dunno.

Re:So, what do you use, then?

[Jaysyn]

Don't feel too bad, I ran A VIA/Win32 box with the AC 97 onboard. Newest drivers & DirectX. The sound still chopped bad enough to make me disable the Audio & throw an generic SoundBlaster card in.

Jaysyn

Re:So, what do you use, then?

[Penguin Follower]

That's the crazy part -- This onboard audio works fine under Windows 2000 (and as far as onboard audio goes... not that bad at all). Since it can work fine, it just bothers me that I get mediocre (at best) results on Linux.

I'm not worried about it, though. Everytime I come across an onboard audio driver that sux in linux, usually the next version of the distro I use has a better driver, and end of problem. :)

YASS (Yet Another Sound Server)

[Anonymous Coward]

Oh, no, Linux isn't fragmented. Not in the slighest. Say, is KDE the one with the cute footprint icon? I can never remember.

Re:YASS (Yet Another Sound Server)

[mlk]

this _should_ (alas, not will) help to unifie UNIX (and a-likes).

AHHH!!

[Hanji]

Run!! Bad Puns!!!

MAS for X or shall I say...

[plip]

h0h0h0 Merry XMAS one and all.

AudioFile

[Anonymous Coward]

Anyone remember AudioFile? It was an audio server whose architecture was roughly similar to X.

Why would I want ducks and cows to warm me?

[Anonymous Coward]

Why not just a audio file yelling, "Hey jerkoff! Your router just cacked!"?

Interesting, but is it Pro Audio?

[Anonymous Coward]

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.

Re:Interesting, but is it Pro Audio?

[i_am_nitrogen]

One of the major reasons there isn't color management and Pantone, etc. color palettes in The Gimp is because many or all of those color processes are patented. Nobody wants to pay for a patent license for every single installation of Gimp out there, and the holders of the patents seem to want to maintain their monopoly on good looking pictures.

It's a similar situation with Hollywood and music/movies. Entry by the little guy is barred by the huge sums of cash being tossed back and forth by the major players. It's pretty hard for a startup indie outfit to survive. Publishing DVD's is even harder, because of all the potential royalties involved.

Slightly OT-Network Audio

[mrmag00]

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.

The prophet has spoken....

[Anonymous Coward]

esound is dying.

The view of the MAS developers

[leon163]

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

Other Applications

[VoidEngineer]

Hmmm... people seem to have liked the other post, so I'll offer some other (potential) practical applications for the sound server. Just my 2 cents...

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!

"But What About Esound? Arts? NAS?"

[nathanh]

I can't comment specifically on arts or NAS, but I know for sure that esound is unusable for network audio. It cannot synchronise audio with video and there is no upper bound on latency. Alan Cox has an amusing quote about esound: something similar to "esound is just about good enough to make a boing noise when you click something, but it's otherwise useless".

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.

Re:"But What About Esound? Arts? NAS?"

[Anonymous Coward]

>>Alan Cox has an amusing quote about esound:
>>something similar to "esound is just about good
>>enough to make a boing noise when you click
>>something, but it's otherwise useless".

Yeah, if you like to wait a half second between the click of your mouse and the boing... only *slightly* annoying...

Finally!

[Erwos]

At least to my way of thinking, one of the Achilles' heels of Linux has been the lack of a unified sound system. We've got the graphics more or less together, but sound has always been quite spotty. Hopefully, this will be the magic bullet which starts getting sound card manufacturers to give Linux and other *NIXs the support they deserve.

-Erwos

Re:Linux audio community has potentially better to

[ivlad]

while it is promising, it is linux-only. MAS, OTOH, tries to provide compatible way for any system...

from their site:

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.

moreover, X license allows companies like Sun or HP to incorporate MAS into their systems. they are not always happy with GPL.

BTW, their web suxx indeed. nasty frames... :/

OMG

[the_2nd_coming]

this will not let XF86 get better!!!!

Re:Linux audio community has potentially better to

[gurensan]

Ok.. I have to say that this, for some godawful reason, is probably the most intelligent post I've seen on this subject on /.. I've been a musician for 16 years, and one of the things I really kinda missed when I made the move to Linux was the lack of really good sound support.

IMO, If this is as good as others say it could be, and if it can provide kernel-level (maybe, with source patches) timecode and sound driver support, they'd really have something. I'd love to record/mix my own stuff on cheap hardware and wouldn't think twice to put on a second X server to do it.

Why not NAS, from a MAS developer

[stem]

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

use LBX, too

[g4dget]

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.

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:use LBX, too

[akeru]

in my experience (and based on my readings of people who know more about such things than I) lbx is of little to no help in just about any situation. Read Keith Packard's "An LBX Post-Mortem" if you want more detailed description of why LBX fails to do what LBX set out to do.

Thank you.

[Ayanami Rei]

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... ::sobs::

MAS is not a tool

[g4dget]

X11 is not a window system, it's a network protocol. That's its strength. XFree86 is a reference implementation.

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.

MOD UP Parent -- Insightful

[cide1]

I agree with this, and I think that these are areas that will take Open Source software to the next level.

3D audio rendering?

[Somnus]

Does anybody know if MAS (or alternatively jack) can handle a driver for 3D audio rendering, not unlike DRI+Mesa in XF86?

Comment removed

[account_deleted]

Comment removed based on user account deletion

A step forward

[HeX86]

I think this could definitely be a step forward. That is if anyone uses it. If people actually decide to use this system it would be really nice to be able to have remote logins and have sound play over the X11R6...

Two things that really hinder open source software:
1) Developers don't plan it out and the code looks like muck.
2) People don't pay any attention to the project.

One thing you need to consider is bandwidth, if you apply any amount of decent compression to X11 data, it could be reduce bandwidth usage by a huge amount.

Perhaps if someone gets a decent setup, you could have people producing dummy terminals that would login to an X11 applicaiton server. It wouldn't be able to run games or anything, but it would definitely be something to consider. I know several schools that use the m$ solution to that, maybe we could get X11 to do that also? The only thing you run into then is removable disk access, printers, usb devices (usb storage).

I'm no x11 genius, but do the current audio servers run over x11, or is it something that needs to be compiled into kde apps, or gnome apps? and can the x11 protocol be compressed?

That's my $.02

Re:A step forward

[psamuels]

Perhaps if someone gets a decent setup, you could have people producing dummy terminals that would login to an X11 applicaiton server. It wouldn't be able to run games or anything, but it would definitely be something to consider.

You're describing 10 years ago: X terminals were quite popular in the early 90s. These are typically diskless, and run via a combination of firmware and an OS downloaded via TFTP or MOS at boot. They are small and have very quiet, if any, fans. Several of the big iron Unix vendors sold X terminals, but NCD carved out probably the biggest market share. (And yes, you can play games over them - Netrek has a full-screen play area yet seems to run fine over 10 Mbit or worse. Today's expectations of full-motion video quality graphics is another matter, though.) NCD invented the first network-based audio server (that I heard of, at least), NAS, which you'll see mentioned in quite a few comments here.

This was way before the term "thin client" was cool.

I know several schools that use the m$ solution to that, maybe we could get X11 to do that also?

Microsoft is very much a johnnie-come-lately here. And they still haven't caught up. I believe they are still using the archaic notion of selling per-client access licenses.

I'm no x11 genius, but do the current audio servers run over x11, or is it something that needs to be compiled into kde apps, or gnome apps?

They run alongside X11. Audio is generally supported at a library level. One such is libao, whose whole point is to abstract away various OS-specific audio output methods, including the various audio servers out there. Some applications seem to prefer to maintain their own audio plugins, effectively doing libao internally.

When a new audio server comes along, some applications will need a new plugin written, while others will continue to use libao and someone will write a libao plugin. It is even possible that existing sound servers like aRts will grow a means to chain to the new audio server, so that applications can continue to use aRts, albeit with higher latency and lower functionality than using the new server natively.

and can the x11 protocol be compressed?

Yes. There was the Low-Bandwidth X extension in the early 90s, but someone (Keith Packard?) investigated it recently and found that it doesn't work that well, so he implemented a new compression scheme a year or two ago. I can't be bothered to go chase down a link.

Good for X

[eonblueye]

Just a pondering suggestion though. First off I know this is way off topic and so on. But why hasn't there been a "strongly" supported or stable project on developing a GUI that is more of a client based system rather then a server? I think if Linux want to advance more towards the desktop users they need to begin to develop for them.

Re:Good for X

[psamuels]

But why hasn't there been a *strongly* supported or stable project on developing a GUI that is more of a client based system rather then a server?

Uh, why? What problems would that solve?

I'm not being flippant. X has served very well in a wide variety of contexts, due to and despite its client/server architecture.

Cue Flashback to 1992

[Anonymous Coward]

You only need the Windows Sound System for "gee neato" sound effects from Windows. I'm not aware of any game or program personally that specifically requires Windows Sound System to be active. CDPLAY.EXE for example can output directly to a SoundBlaster using a TSR.

Re:Cue Flashback to 1992

[eviltypeguy]

As far as your comments regarding the "SoundBlaster TSR", they don't really apply here. OSS is an established, openly documented interface while the SoundBlaster TSR you mention was a proprietary interface.

ALSA and/or MAS?

[Anonymous Coward]

Could someone clear up the situation for some of the newbies.

ALSA is a sound server... MAS is the same? Would they work together, or be distinct choices. What advantages does MAS have over ALSA? What drawbacks?

Thank you for your time,
Anon

Re:ALSA and/or MAS?

[La Temperanza]

For starters, MAS doesn't assume everyone uses Linux.

The X Consortium's LBX = "Low Bandwidth X"

[Walles]

The reason for not compressing stuff by default is to keep latency low. As long as you are on a LAN, this is a good idea, and is so by design.

For people wanting to use X over low bandwidth connections, the X consortium (?) in their infinite wisdom invented LBX ("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.

Audio server, why?

[Anonymous Coward]

Why do we need an audio server for local applications, when almost every soundcard is getting hardware mixing drivers?

MotU anyone?

[Anonymous Coward]

Why MAS, when there already is MAS? To all non-musicians: MAS (from MotU) is a widely used audio system in the professional audio world.

Does this mean...

[gostats]

the name of this is X-MAS?

What, no cheap jokes yet???

[Pflipp]

Then *I* must do it, and so I will!

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>

Re: Incompatible design criteria

[Ricdude]

The problem is that without some level of integration with the video system (i.e. X), synchronizing full audio/video streams via an external daemon mixing process will result in noticeable latency. That latency can be minimized to about 100 ms or so before you run into the problem of "stutterring" audio streams (audio not reaching the mixer fast enough). This latency is irrelevant for "long, continuous" streams (such as mp3's), and barely noticeable for "sporadic" events (window manager squonks, game bleeps, etc.).

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...

Bullshit

[Anonymous Coward]

That is not "insightful."

Linux has /dev/dsp, /dev/mixer, /dev/midi, you don't need some special daemon when sound is built into the operating system.

Dangling String URL

[Anonymous Coward]

Look towards the end of this paper. It describes that "dangling string network monitor".

Reply to all.

[FreeLinux]

Let me say this again. X11 is a bandwidth hog. Numerous posts above defend it and try to explain why it uses so much bandwidth. A few posts seem like nothing more than defenses based on emotional attachment to X11. But, the fact remains that it uses too much bandwidth.

Numerous posts blame the high bandwidth on "poorly designed applications". This says that there needs to be a different protocol. It should not matter what the application is or how badly designed it is the display server should be able to reliably and consistantly export the display, regardless of the underlying application. If it shows up on the screen the display server should be able to push it across the network at a reasonable cost(bandwidth).

A few incredulous posts say that the problem is my use of "eye candy". Excuse me???? Remember that we are talking about X. X is a *GUI* display manager. If we cut out the GUI part, then we don't need X at all and can happily rely on SSH. The whole point of X is eye candy. What kind of display manager is it if it chokes on the *display*.

A few posts say that my numbers are way off base. They site their own experiences at 2Mbps and 200kbps. Regarless of my numbers, 200kbps for a static image is WAY too high, let alone 2Mbps or 11Mbps. See below for more acceptable bandwidth numbers.

As is always the case a few people piped up and offered VNC. VNC is a very nice remote control package but, it really can't be compared to X11 and similar products since VNC does not offer the same functionality. VNC does allow you to remotely control a desktop but X11, RDP and ICA do much more than that.

Which brings us to examples of protocols that offer similar X11 functionality at a MUCH lower bandwidth. VNC is relativley low bandwidth but, as stated above, is less functional than X. RDP consumes about the same amount of bandwidth, up to 200Kbps, but provides much greater graphics quality and far greater responsiveness than VNC or X. But, Citrix ICA is the hands down winner. It offers very similar functioinality to X much better performance than X, VNC or RDP and it is the lowest consumer of bandwidth.

A standard desktop application(not too graphics intensive) can consume as little as 14Kbps. It is possible to have 32 bit color depth with animated graphics(even a movie) and sound running on Citrix ICA at 200kbps or less. The average ICA session consumes 30kbps.

All this means that it *IS* possible to have a networkable display that consumes a minimal amount of bandwidth. X11 using 200kbps to 11Mbps is WAY too high. X needs a new protocol.

compile your own damn kernel

[SHEENmaster]

and get the better drivers now!

At some point you will come across that needed driver that your distro's kernel doesn't have; until then, enjoy not worrying that you forgot to reload your bootloader after compiling.

what a mess

[Anonymous Coward]

As if there weren't already a problem of too many existing solutions to *nix audio... We just need to pick something and make it a standard. Think about the success of X. Sure, there are much better tools out there interacting with users in a graphical manner, but X has worked so well because the unix community adopted it as a standard.

Think about how much code gets re-written. arts, esound, jack, and now mas. We really should just pick one and go for it. If you think it's lacking functionality, then change it, for crying out loud! That's what open source is all about!

At a certain point when everyone's running around like chickens with their heads cut off, it begins to appear that a poor standard would be better than no standard at all.