The major topics were the Nvidia and ATI drivers: how fast will they be ported? or will there be binary compatability?
I don't think there has to be special support in the drivers to support this. The composition client is just another process (like the window manager) so it doesn't do extra driver calls or sth.
The reason that X is slow locally is because 2D windowing isn't directly rendered
Actually there were some folks who implemented direct rendering for 2D in X and guess what, it didn't make any difference! The problem is not direct rendering, it's the inefficiency of Xlib (e.g. requiring replies when it's not needed, etc).
In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.
Looks like you know even less about X and sockets. There are problems with X/XFree86, but they're not what you're describing.
If you have DSL you should still use your upstream SMTP server for outgoing mail. About 90% of incoming SPAM on my box originates from Windows boxes on DSL lines with open relays. I've set up exim to ignore all incoming SMTP calls from dsl hosts (*.dsl.*) and also to block hosts without proper reverse-DNS. These 2 simple steps take care in blocking a huuuge quantity of incoming SPAM at the doorstep...It's not fullproof, but it helps a great deal.
Once you get an incompatible fork it will loose that and fall into total disarray
This is not going to be the case at all. The "fork" will adhere to all the current standards. It will just be possible to develop different parts of the systems at a faster pace. It's also supposed to get us new goodies, that are build on the standard protocols, faster, and that's a good thing for the OSS cycle (hack, release, feedback, hack, release,...ad infimum).
Have a little faith, xwin is in good hands. The xwin people are mostly responsible for the cool new stuff we're using right now anyway.
If anyone knows about any open source Sequencer with planned VST support, let me know, I would love to help. I searched Sourceforge for Linux VST.. and found nothing.
So, anyone know a soundcard that will let me play mutiple streams WITHOUT having to use esd/artsd, and is decently well supported under Linux? Anyone? BTW, can we keep it under $100 (USD) if possible?
Trident 4DWave NX/DX based cards are excellent! Not sure if they're still available though. For about $20 you get a card with S/PDIF out and at least 16 stereo pcm devices with ALSA. I bought a couple of them at Hoontech Taiwan (just checked. no longer available from their site).
But check out the ALSA Soundcard Matrix and look for entries which have Note (4), hardware mixing support.
Contrast with the monolithic kernel that linux has. Creative would need to participate and coordinate with linus et al from start to finish.
Erh no! Most, if not all drivers in ALSA were written without any interaction from the kernel folks. ALSA is now integrated in the 2.5.x kernel, but that doesn't mean driver developers will have to deal with Linus et al. They just deal with Jaroslav, the ALSA maintainer. All mainstream cards are already supported by ALSA. If a company doesn't want to provide docs it can always choose to write and distribute their driver on their own.
In short, the monolithic kernel is an albatross around linux' neck when it comes to wanting hardware support from the manufacturers.
The upcoming version of AlsaPlayer will support FLAC streaming over HTTP, and even seeking if you use HTTP 1.1. We should see FLAC streaming support in Icecast soon, at least I hope so.
NVidia still hasn't realeased a set of drivers that work with the 2.5.x development kernel which, unfortunately, I must use day-to-day -- albeit on a non-production machine.
NVIDIA has better things to than chasing a constantly changing interface (Kernel 2.5.x). The patches available at http://www.minion.de/ were updated for practially every kernel release between 2.5.44 and 2.5.50. Surely you don't expect NVidia to roll new drivers every 2 days, right?
With that said, I can finally enjoy Twinview with dual X screens in the 41.91 release. Their new 2D architecture still needs lots of work though...looking forward to the next release.
The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit).
The skipping is caused by scheduling latency, as Paul suggests. I have written an mp3 player for Linux (see URL) and it only really skips when the audio output thread is not scheduled in time to satisfy the soundcard's needs. I.e. the Linux scheduler needs to make sure that whenever the audio thread wants to fill the soundcard buffers it must get the highest priority to do so. For example if you are using a soundcard buffer that is split into 2 fragments of 1024 bytes each that means that the audio thread needs to be scheduled every 6ms, 3ms for 512 byte fragments (44KHZ stereo, 16bit output). Even when your soundcard buffer size is 50 or 100ms deep you can very easily cause skipping if your audio thread is not scheduled for 100ms or longer. And this is pretty normal on a vanilla kernel for non-realtime scheduled processes. Think about it, your "cat >/dev/zero" has the same priority as your audio thread so they have equal rights to the CPU, however the audio thread has much stricter scheduling needs since you will get audio skips whenever it is scheduled too late (i.e. the soundcard buffers get depleted)
In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk). In the end it doesn't really matter because your music still skips, but it is important to identify exactly why it's skipping.
XFS smokes BeFS. Hell, even the open source OpenBFS BeFS implementation is heaps faster than the original beast:). The other funny thing is that BeFS was actually inspired by XFS.
-adnans
Re:UT2k3 - linux impressions
on
UT2003 LiveCD
·
· Score: 3, Insightful
I am quite disapointed that linux faired so much worse on my system, I really do hope that either I screwed something up or it is a peculiarity of my system or the beta level software.
It's reallly ver simple. The OpenGL UT2003 drivers are pretty much unoptimized at this point. Remember, the main renderer engine for UT is D3D which means that the game will run faster in D3D mode. Using the OpenGL engine under Windows will probably yield the same crappy result. But then again a dual Celeron 333 is really not up to speed and doesn't even come close to the minimum advertised requirements for UT2003 (At least a PIII 700, etc..). Upgrade!;-)
"Quartz Extreme" for XFree86 anyone? I have a huge amount of power locked up in my NVidia Gefore4 Ti card, wish I could use it for my regular 2D work (blending, translucancy, etc.)
How about using an application that was designed from the ground up to do voice over IP instead of this voice chat shit hacked into an IM client?
Actually, the IM usually serves purely as a broker or VoIP directory if you will. A specialized VoIP can be spawned once the information is worked out in the IM. If your mom gets dropouts or otherwise shitty performance it's probably just her shitty Internet connection. Get her a decent broadband uplink.
-adnans
Voice Over IP support
on
Gaim For Windows
·
· Score: 3, Interesting
Does anyone know if GAIM is going to support Voice Over IP? IMHO that's the killer app for any IM platform.
... that a project like this, which claims to "implement high quality, anti-aliased and subpixel rendered text on a display" can have such an ugly website without any screenshots.
Since fontconfig itself doesn't deal with font rendering / displaying it doesn't make much sense to have screenshots there. You should check out the Pango / Qt / GTK+ / etc. websites for screenshots. Or do you also expect screenshots of linux on kernel.org?:-)
Slashdot Mirror
The major topics were the Nvidia and ATI drivers: how fast will they be ported? or will there be binary compatability?
I don't think there has to be special support in the drivers to support this. The composition client is just another process (like the window manager) so it doesn't do extra driver calls or sth.
-adnans
You gonna rewrite ssh?
No, just modify it so it understands these extra attributes (both server and client). That shouldn't be too hard.
-adnans
The reason that X is slow locally is because 2D windowing isn't directly rendered
Actually there were some folks who implemented direct rendering for 2D in X and guess what, it didn't make any difference! The problem is not direct rendering, it's the inefficiency of Xlib (e.g. requiring replies when it's not needed, etc).
In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower than it could for everything except remote use.
Looks like you know even less about X and sockets. There are problems with X/XFree86, but they're not what you're describing.
-adnans
If you have DSL you should still use your upstream SMTP server for outgoing mail. About 90% of incoming SPAM on my box originates from Windows boxes on DSL lines with open relays. I've set up exim to ignore all incoming SMTP calls from dsl hosts (*.dsl.*) and also to block hosts without proper reverse-DNS. These 2 simple steps take care in blocking a huuuge quantity of incoming SPAM at the doorstep...It's not fullproof, but it helps a great deal.
-adnans
Once you get an incompatible fork it will loose that and fall into total disarray
...ad infimum).
This is not going to be the case at all. The "fork" will adhere to all the current standards. It will just be possible to develop different parts of the systems at a faster pace. It's also supposed to get us new goodies, that are build on the standard protocols, faster, and that's a good thing for the OSS cycle (hack, release, feedback, hack, release,
Have a little faith, xwin is in good hands. The xwin people are mostly responsible for the cool new stuff we're using right now anyway.
-adnans
IMHO, the real strength of MPLayer is that it doesn't need ANY GUI! Just fire it up in fullscreen and enjoy the Movie.
-adnans
If anyone knows about any open source Sequencer with planned VST support, let me know, I would love to help. I searched Sourceforge for Linux VST.. and found nothing.
i s-month/0020.html
http://boudicca.tux.org/hypermail/jackit-devel/th
Google around for details...
And ALSA is the way every card will work from now on? Or will it change to something else with kernel 2.6?
:-).
The ALSA API in kernel 2.5.x will be the same one in kernel 2.6.
Vendors like standards and specifications. They dont like researchers and academics and expiriments.
Vendors look at the bottom line. If there's enough incentive they will write against any API (*cough* Windows *cough*
-adnans
So, anyone know a soundcard that will let me play mutiple streams WITHOUT having to use esd/artsd, and is decently well supported under Linux? Anyone? BTW, can we keep it under $100 (USD) if possible?
Trident 4DWave NX/DX based cards are excellent! Not sure if they're still available though. For about $20 you get a card with S/PDIF out and at least 16 stereo pcm devices with ALSA. I bought a couple of them at Hoontech Taiwan (just checked. no longer available from their site).
But check out the ALSA Soundcard Matrix and look for entries which have Note (4), hardware mixing support.
-adnans
Contrast with the monolithic kernel that linux has. Creative would need to participate and coordinate with linus et al from start to finish.
Erh no! Most, if not all drivers in ALSA were written without any interaction from the kernel folks. ALSA is now integrated in the 2.5.x kernel, but that doesn't mean driver developers will have to deal with Linus et al. They just deal with Jaroslav, the ALSA maintainer. All mainstream cards are already supported by ALSA. If a company doesn't want to provide docs it can always choose to write and distribute their driver on their own.
In short, the monolithic kernel is an albatross around linux' neck when it comes to wanting hardware support from the manufacturers.
Nonsense.
-adnans
The upcoming version of AlsaPlayer will support FLAC streaming over HTTP, and even seeking if you use HTTP 1.1. We should see FLAC streaming support in Icecast soon, at least I hope so.
-adnans (*plug*!)
I decided to mothball my BeBox until it's worth at least as much as what I paid for it originally, taking into account inflation, etc.. :)
-adnans
NVidia still hasn't realeased a set of drivers that work with the 2.5.x development kernel which, unfortunately, I must use day-to-day -- albeit on a non-production machine.
NVIDIA has better things to than chasing a constantly changing interface (Kernel 2.5.x). The patches available at http://www.minion.de/ were updated for practially every kernel release between 2.5.44 and 2.5.50. Surely you don't expect NVidia to roll new drivers every 2 days, right?
With that said, I can finally enjoy Twinview with dual X screens in the 41.91 release. Their new 2D architecture still needs lots of work though...looking forward to the next release.
-adnans
MUTT with PINE bindings!
-adnans
Your command line can be much shorter:
make xconfig dep clean bzImage modules modules_install
-adnans
Don't you mean his grandchildren? :-)
Sadly yes, they didn't change the theme song. But it's starting to grow on me.
-adnans
Just finished watching 2x01! Satellite feeds rock! :-)
-adnans
The problem comes when reading an mp3 from disk (and no, this is not a "DMA/umasked interrupts" is not on issue) and other *heavy* sequential disk i/o is being done by another piece of software (because of the amount of data, tar xzvf is frequently the culprit).
/dev/zero" has the same priority as your audio thread so they have equal rights to the CPU, however the audio thread has much stricter scheduling needs since you will get audio skips whenever it is scheduled too late (i.e. the soundcard buffers get depleted)
The skipping is caused by scheduling latency, as Paul suggests. I have written an mp3 player for Linux (see URL) and it only really skips when the audio output thread is not scheduled in time to satisfy the soundcard's needs. I.e. the Linux scheduler needs to make sure that whenever the audio thread wants to fill the soundcard buffers it must get the highest priority to do so. For example if you are using a soundcard buffer that is split into 2 fragments of 1024 bytes each that means that the audio thread needs to be scheduled every 6ms, 3ms for 512 byte fragments (44KHZ stereo, 16bit output). Even when your soundcard buffer size is 50 or 100ms deep you can very easily cause skipping if your audio thread is not scheduled for 100ms or longer. And this is pretty normal on a vanilla kernel for non-realtime scheduled processes. Think about it, your "cat >
In short, the soundcard will be starved of ready to play PCM data long before the decoder will be starved of MP3 encoded data (from disk). In the end it doesn't really matter because your music still skips, but it is important to identify exactly why it's skipping.
-adnans
XFS smokes BeFS. Hell, even the open source OpenBFS BeFS implementation is heaps faster than the original beast :). The other funny thing is that BeFS was actually inspired by XFS.
-adnans
I am quite disapointed that linux faired so much worse on my system, I really do hope that either I screwed something up or it is a peculiarity of my system or the beta level software.
;-)
It's reallly ver simple. The OpenGL UT2003 drivers are pretty much unoptimized at this point. Remember, the main renderer engine for UT is D3D which means that the game will run faster in D3D mode. Using the OpenGL engine under Windows will probably yield the same crappy result. But then again a dual Celeron 333 is really not up to speed and doesn't even come close to the minimum advertised requirements for UT2003 (At least a PIII 700, etc..). Upgrade!
-adnans
"Quartz Extreme" for XFree86 anyone? I have a huge amount of power locked up in my NVidia Gefore4 Ti card, wish I could use it for my regular 2D work (blending, translucancy, etc.)
-adnans
How about using an application that was designed from the ground up to do voice over IP instead of this voice chat shit hacked into an IM client?
Actually, the IM usually serves purely as a broker or VoIP directory if you will. A specialized VoIP can be spawned once the information is worked out in the IM. If your mom gets dropouts or otherwise shitty performance it's probably just her shitty Internet connection. Get her a decent broadband uplink.
-adnans
Does anyone know if GAIM is going to support Voice Over IP? IMHO that's the killer app for any IM platform.
-adnans
Since fontconfig itself doesn't deal with font rendering / displaying it doesn't make much sense to have screenshots there. You should check out the Pango / Qt / GTK+ / etc. websites for screenshots. Or do you also expect screenshots of linux on kernel.org?
-adnans