Slashdot Mirror
First Xouvert Milestone Released
An anonymous reader writes "
The first milestone of xouvert, the X-server replacement has been released. Xouvert includes MAS giving the X server its very own sound server. Nice. :) Also, just noticed that enlightenment quietly released an update to the 0.16 series.
" (Here's a link to the Xouvert download page.)
Xouvert represents far more then merely tranparent windows etc, it represents a move to a more recognisable OSS model of working. XFree86 is charterised by a fairly closed development process, long patch intergration times, and close control by the steering group. I am greatly looking forward to seeing a true open source methodolgy accelerate development.
"To any truly impartial person, it would be obvious that I am right."
..is an answer to Apple's Quartz 2D rendering capabilities.
Linux isn't going to make a dent in the desktop world until it's significantly better than MS windows, not just politically, but in ease of use, quality of rendering, integration, etc, etc.
Linux already does OpenGL. Take the next step; Apple's already shown you what to do.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I've used NAS for quite some time now. many apps are already compatable with it. (madplay mpg123 xmms gnome sound server) and it works great for X terminals to get sound (and hogs network bandwidth like no tomorrow)
is MAS anything like NAS? is it compatable?
Do not look at laser with remaining good eye.
We haven't needed esd and arts from the first place if sound would be handled by X since the beginning.
Because that's what X is supposed to do - to isolate window managers, desktop managers and just applications from any knowledge about hardware. Gnome or KDE should just fire the sound event, not actually handle it.
I hope that at some point Gnome and KDE developers will drop their "proprietary" sound servers and just send sound events in a same way as they now do with graphics events. THEN perhaps Gnome and KDE will have more available human resources to *focus* on improving the usability and configurability of their applications.
Less is more !
I don't understand why YOU were posted flamebait, and the notoric liar hasn't been modded down at all.
Will you lazy moderators at least do some research when you're told?
He claims to be working for AT&T, Apple, Honda, and now for the Xouvert project. He's also doing someone else's taxes, and he's transmission engineer.
If you don't believe me, then read his history.
I'm posting this as AC because the moderators seems to be a bit out of control.
As for playing sound "fast", all you really want is minimal lag between sound being queued on the server and being put out on the speaker. The main problem there is network lag during congestion; I guess that could partially be offset by (a) a good, switched network and/or (b) QoS providing audio with a higher priority.
The subject pretty much says it all ...
Read this or this for more info.
Death to ESD/ARTS today!! (and maybe even JACK, if we can low enough latency).
Sunny Dubey
We don't complain about X, we complain about Xfree.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
I don't think the original poster is anti-Unix, he just feels that the "GUI" aspect of X should encompas sound, just like X servers now handle keyboard and mouse events.
/dev/dsp.
Sound apps not needing to know the hardware is no different than X applications not needing to know the hardware when they make xlib calls.
Right now, every system that wants to provide network transparent sound has to reinvent the wheel since no one can agree on the "right" way to do it. Having one chosen as the "blessed" one by Xouert may end the argument.
As to requiring esd outside X, I don't see much of the point. I suppose you *could* do sound in consoles with something like emacs or screen, but that's highly unusual. Most people want sound events locally, so outside X you can send events right to
As to the issues of large monolithic code, I tend to agree, but think that the original poster's comment didn't necessarily imply code bloat, only a "blessed' X sound event system that comes with a new X server and makes it easier for application developers to write code that will run sound over the network (which will make projects like the Linux Terminal Server project easier).
- Serge
The idea is that you start up MAS instead of whichever Networking sound solution you are using now. MAS is a stand alone server taht can run without X... in fact there are others you could use, but then MAS was developed with professional audio and video conferencing in mind (both needing low latencies) and MAS is has a solid suport from the X consortium behind it. Both are thing I most alternatives can not claim for themselves.
Regards, Tobias
why, oh why does this ctrl-alt-+ ctrl-alt-minus keep coming up everytime someone mentions they want to change their desktop resolution?
to a user, this doesn't change the resolution. it seems more like a zoom in, zoom out feature. great if you need to zoom in/out. but if you want to change resolution, you're not going to find it here. a user would want to be in a 1024x768 resolution, have a browser window maximized, and change the resolution to 800x600 and still see that window maximized (and have that entire window displayd on the monitor w/o having to move their mouse around).
maybe XFree86 could go a step further than implementing a Microsoft change resolution feature. give the ability to have different resolutions on different virtual desktops. that's where it gets close to window manager implementation to me. it would be nice to have one virtual desktop with 800x600 resolution, and one with 1024x768 or what ever the user prefereances are. it would be nice if XFree86 could give each window the ability to be shown it its own resolution.
My old Agenda VR3 had a total of 8mb RAM and 16mb Flash- 13mb for the kernel and all programs. It ran XFree86 and FLTK. It was plenty speedy and never had a memory problem.
Just a Tuna in the Sea of Life
The statement about being anti-Unix is very unwise.
What if the creators of Unix back around 1970 had had terminals with built-in speakers? How high do you think are the odds that they wouldn't have included audio into the concept of a computer terminal?
I bet you almost anything that we'd have a stdpcm in ISO C today.
It is absolutely ridiculous that the concept of a terminal only contains the lowest common denominator of text input and output. You should think of the terminal as an interface to the user. It logically follows that all kinds of other devices can become part of an interface, depending on the situation.
Obviously, sound in/out can be a part of an interface. A USB port or a DVD drive could be part of an interface. After all, the one who physically "sits" at a device should automatically be able to control it (yes, there are exceptions, such as computer pools - the keyword is "exception", though). This would automatically eliminate all those ugly permission hacks that are necessary today, by the way.
One could even imagine an interface that consists of only sound in/out *without* any form of text or video interface (e.g. interface for the blind).
You have correctly identified the competition to MAS: JACK. Some of my colleagues and I have been wondering aloud whether one could build a nice interface to JACK for network audio. It looks like the answer is yes.
As you correctly note, the real issue is latency. Servers like MAS cannot generally promise reasonable latency on the local side: latency matters there (indeed, it's all that matters).
Dmix looks cool too, but as folks have pointed out, it's going to be tough to get it to work with the range of systems X runs on. Unless it's optionally layered atop JACK...
Nah... triple buffering is totally and utterly quick! (as long as you've got enough video memory to perform the necessary operations) -- and the code isn't that complex (or shouldn't be if you do it right!)
/really/ small: you are really only executing (1) the logic described in my last post (to keep track of in use buffers, and s/w locking them, etc), (2) a little interrupt handling (hey! we're now in the offscreen period!) and (3) some h/w access (method to switch visible surface: flip or blt)
/etc (heh, if you're writing for the PC you have more variations to take into account, you'll end up using double/triple buffering if you want speed and a clean redraw - the API is easy to work with, no matter what's underneath).
/cleaner/, and it should also be quicker due to the above points).
/will/ be a performance hit of some kind (somewhere on the system) when you flip (or shortly after).
There should be negligible (dare I say zero?) performance hit if you use it on your primary visible surface -- triple buffering isn't for the individual windows, it'd be used only for the surface you composite your main onscreen view onto.
The overhead from executing code to achieve (triple) buffering is
Also, you start to gain performance from using back buffers because you avoid hardware memory locking issues. If you only have a primary buffer to draw to, with every 'blit' that takes place the hardware has to be available (not processing another request), and the destination memory must not be in use by any other hardware operation (reading RGB pixel array of visible surface to convert into a video signal).
By ensuring you are writing/modifying an offscreen surface you always ensure that the memory you are accessing is not in use by the video h/w.
The back buffer should, in theory (esp. in triple buffering) be completely free for you to do as you wish with -- free of any h/w locking through memory accesses, etc. -- and there should always be a surface freely available so when you say 'can I have a surface to draw on please?' there is no wait for a surface to unlock.
Obviously, some of the above issues may not be issues with some of the memory types fitted to very modern PC graphics cards (modern and trendy double dma, 0ws, doo-diddly-dangle super-vram), but I believe they still come into play on a lot of common PC video hardware that people use. It depends on the exact video chip / memory
Nowadays things are also made a bit easier as most of the modern video cards have a proper vblank interrupt -- obviously, some h/w doesn't support such a thing, in which case you'll have a hard job getting rid of the ugly shearing you describe (but using a back buffer will still make the refresh
Most fullscreen/games APIs that I've worked with (on both sides) have allowed double/triple buffering, it's fairly common.
In any extremely rare cases (of h/w) where triple buffering does not improve performance, the loss (through added code execution) should be sooo small as to be totally insignificant -- and you've still gained a cleaner screen update as a result.
Oh yeah... triple buffering will only work as intended (ie: at full speed) if you have all (3) of the surfaces in video ram. If you can't/don't then there
Perhaps the Arch model just assumes a single master committer - but unfortunately most development projects I have worked on do not work that way. I see this issue chasing potential Arch users away until it is definitively resolved or adequately explained in the Arch FAQ.
There's a project called "tla-pqm" that makes an attempt at solving this. The developers can email a merge request to a tla-pqm server somewhere, and the server will grab the requested changesets and apply them to its archive. It's like an automated master committer.
Does anyone know how this issue was ultimately resolved by the Xouvert project?
I'm pretty sure they have a special committer account, and all developers can access it via sftp using ssh shared keys.