X11 7.7 Released, Brings Multi-Touch Input

First time accepted submitter Jizzbug writes "The X Window System made release X11 7.7 last night (June 9th): 'This release incorporates both new features and stability and correctness fixes, including support for reporting multi-touch events from touchpads and touchscreens which can report input from more than one finger at a time, smoother scrolling from scroll wheels, better cross referencing and formatting of the documentation, pointer barriers to control cursor movement, and synchronization fences to coordinate between X and other rendering engines such as OpenGL.'"

Comments

Wht not sound?

[Anonymous Coward]

X virtualises user interface devices: mice, keyboard, display. Why sound has always been outside? Is not it another part of user interface?

Why we have these incompatible "sound servers", if the X protocol could be used instead? Tunneling a video with sound through X through ssh through Internet? No problem.

Re:Wht not sound?

[KiloByte]

It's hard enough getting sound to work well locally

Nah, just try "apt-get purge pulseaudio".

Re:Wht not sound?

[ChrisMP1]

Am I the only one who's never had a single problem with Pulse? What is it doing for everyone else that makes it so bad?

Re:Wht not sound?

[Anonymous Coward]

It used to be very crash prone, laggey and with a whole lode of audio glitch issues. It has not caused any serious issues for me for about 2 years now, and complaints form new users have dropped dramatically so it seems to have improved quite a bit. You do not want to use it for low latency audio and there are a few specific pieces of hardware that do not work but most complainers either oppose its design principles or still hate it due to long memories rather than current issues.

Re:Wht not sound?

[fa2k]

I think the reason people don't like it is that it introduces a fair number of problems, and it only has benefits in some rare, specific circumstances

Pulse seems to have been introduced at the wrong level, for what it is. Because it works on top of ALSA, it relies heavily on some little used functions, such as getting the true decibel level of the volume controls. (This causes the PA volume controls to fail for some hardware, such as muting the audio at 25 %). On the other hand, it doesn't make use of all ALSA functions, so it does resampling and mixing in software, instead of relying on (possibly superior) hardware. It also doesn't expose all functionality of the underlying devices, and I think it was difficult to get passthrough of digital audio to work about 6 months ago. So it's a rich API built on top of another rich API, offering little benefit, and introducing some bugs.

Re:Wht not sound?

[TheRaven64]

Sound works fine on FreeBSD, no need for ugly hacks like PulseAudio, just in-kernel low-latency sound mixing and a full OSS4 implementation, complete with per-application volume controls, surround sound, and all of the features you'd expect of a modern operating system.

Re:Wht not sound?

[aardvarkjoe]

You do not want to use it for low latency audio and there are a few specific pieces of hardware that do not work but most complainers either oppose its design principles or still hate it due to long memories rather than current issues.

I recently updated from debian squeeze to wheezy, and in the process it reinstalled pulseaudio. Surprise, surprise: my computer crashed frequently until I got rid of it again.

Sound on Linux has been very problematic the entire time I've been using it -- since the late '90s. It's turned into this weird tinker-toy arrangement where nothing quite works right, and debugging problems when you have them is extraordinarily painful.

Right now, the best solution I've found is to nuke all of the ALSA, pulseaudio, and other userland crap and go with OSSv4 -- it's been very stable for me over the last few years, and since it's self-contained at least solving problems doesn't take finding a needle in a haystack. The biggest downside is that (at least, AFAIK), it's not supported by mainstream distros, so if you're not comfortable recompiling your kernel and modules it's not usable.

Re:Wht not sound?

[Nimey]

In my experience Pulse will sometimes not work at all, and other times when you change the system volume it will lag on changing quite a bit or make the sound mute briefly.

I had a much better experience overall with ALSA and ESD.

Re:Wht not sound?

[ffflala]

Pulse killed the possibility of multitrack recording studio on Linux. You can still look back and witness the dramatic die-off of multitrack Linux uses and discussion that coincide with the introduction of Pulse. It's like going back and looking at MySpace, or Friendster.

Right before Ubuntu brought in Pulse, I'd finally hit a sweet spot with Linux audio. With ALSA + qjackctl I was able to manage low-latency multitrack audio recording, and simultaneously have discrete control over the audio of all media players. Before pulse, I was able to use my terminal as a giant mixing board, managing recording and various media playback simultaneously. Different mixes and levels for different apps -- I was able to discretely control the audio levels and mixes for *each channel* in surround sound.

Pulse completely destroyed these capabilities, it eliminated the low-latency capability necessary for multitrack recording, and replaced it with frequent crashes, inconsistent behavior, and was tied in so deeply that Ubuntu has never since been capable of the audio layout I'd been using about five years ago.

Pulse is the single worst Linux move I've ever seen. In the interest of removing audio from the kernel space (necessary for low-latency), it simply eliminated what used to be advanced capabilities. Lennart Poettering, author of Pulse simply disregarded these concerns, waved his hands and said "that's not the concerns Pulse was designed to address!"

No shit, Lennart.

Re:Wht not sound?

[Tore S B]

Because the distros put it in way the hell to early, a point at which there were plenty of kinks, and the benefits had not been made visible in a meaningful way in any UI I noticed.

There's only so many times you could end up with random sound problems which were solved - with no loss of functionality - by killall pulseaudio - or more permanently...

rm /usr/bin/pulseaudio
ln -s /bin/cat /usr/bin/pulseaudio

...without developing a certain animosity towards that binary.

Re:Wht not sound?

[Hatta]

It's really time for the kernel guys to take another look at OSS4. Fully GPL compatible, it belongs in the kernel.

Re:Wht not sound?

[RobbieThe1st]

To be honest, I agree with it's choice to hardware mix/resample in software - Most cards(by volume) are just dumb DACs, and the few that aren't(like my audigy 2) have enough bugs to make it useless to try - Just use ALSA straight on those cards, or only use Pulse for that application(which works perfectly well when you have a hardware mixer).

Re:Wht not sound?

[LizardKing]

BSD people look at you strangely if you try to get Pulse working

That's because Pulseaudio was designed to solve issues that for the most part have never existed on BSD systems. The BSD's evolved their existing OSS based audio subsystems to fix the few issues it had, whereas Linux chose to adopt a poorly implemented new system. I speak from experience, having tried to write an OSS shim for NetBSD that emulated the ALSA MIDI API, and became frustrated by the incomplete, innacurate documentation. I was also bemused by the ALSA API itself which looked like it was designed to be object oriented, but actually implemented by people with no real understanding of good OO princples.

Re:Wht not sound?

[Anonymous Coward]

Since you're flaming, I can flame harder.

Disclaimer: I've sent some patches to pulseaudio and alsa.

Pulseaudio is possibly the best thing that has ever happened to linux, the introduction was unquestionably problematic, but dmix that it replaced will not be missed. It also contains features that decrease the amount of interrupts needed, and it didn't work around problems in hardware but fixed. If you feel like it you can STILL use jack, in fact with -rt kernel I ran pulseaudio on top of jack in a 2.5ms maximum latency configuration with 0 underruns for native jack clients.

In the time that only dmix existed, a lot of features were missing and you couldn't guarantee that something that happened to work on your card would ever work on someone else's card and all names for the master channel was inconsistent and the dB levels were usually garbage. You have the people who worked on pulseaudio and fixed the upstream bugs instead of hacking around them to thank that those problems were actually fixed.

Re:Wht not sound?

[Anonymous Coward]

Pulse killed the possibility of

Why not use jackd directly on top of alsa and pulseaudio as a client for jack? You could use pulseaudio for all desktop stuff that doesn't need low latency which I believe would only use one jack slot (or whatever it is called) and all latency critically things could connect directly to jack.

pacmd suspend true
sudo jackd -d alsa
pactl load-module module-jack-sink channels=2
pactl load-module module-jack-source channels=2
pacmd set-default-sink jack_out
pacmd set-default-source jack_in
pacmd suspend false

Or something like that.

Re:Wht not sound?

[zixxt]

Sound works fine on FreeBSD, no need for ugly hacks like PulseAudio, just in-kernel low-latency sound mixing and a full OSS4 implementation, complete with per-application volume controls, surround sound, and all of the features you'd expect of a modern operating system.

That's one thing the BSD's got right. However Linux had an old and unmaintainable version of OSS, so ALSA had to kill it off in Kernel. PulseAudio is a nasty bloated buggy piece of crap, even old ESD works far better IMHO.

So the same guy that made system boot configuration and init scripts a huge pain in the ass with systemd is also responsible for screwing up our sound support? Somehow I am not surprised by this....

Amen!

Re:Wht not sound?

[MrHanky]

Yes, but I don't think those users would compile OSSv4 to get around ALSA and PulseAudio's failures.

Re:Wht not sound?

[rec9140]

So... do what every one else does.... DONT USE IT!

I removed it via a hack... by doing a force hack mv on the pulsecrap bin... hackish very hackish.

Now I just remove the packages in synaptic and let ALSA take over in Phonon like it should.

So just remove it and go back to doing what you were doing.

Yes its an uneeded and annoying to have to do this, but just like the other PITA project, WAYLAND, the too young to have been alive when X or ALSA came about have their heads buried on what is the "better path."

Re:Wht not sound?

[smash]

You do not want to use it for low latency audio

So, what are you supposed to use it for? Given that gaming isn't exactly Linux's forte, and audio production is a more likely niche, which requires low latency audio, what problem is pulse trying to solve. Having multiple audio solutions because the primary one can't do low latency is retarded.

Meanwhile, FreeBSD has done multi-channel audio out of the box without any grief since at least 2005.

Re:Wht not sound?

[ffflala]

I started learning *nix w/ FreeBSD back towards the end of the 4.x series, and stuck with FreeBSD through the beginning of 6.x. As fond as I am of the BSDs, they are fundamentally incompatible with multitrack *recording*.

Multitrack recording is where you record a track or tracks while listening to and playing along with a prerecorded track. This requires extremely low latency -- you need to be able to play something and hear it back as close to instantaneously as possible. Latency needs to be at a lower time threshold than you can perceive, and about 6 microsecond is the threshold (though that's pushing it.) Any latency larger than that, and the newly recorded tracks will be noticeably out of sync with the playback tracks.

This part is beyond my knowledge (please forgive and correct any inaccuracies, respected kernel hackers) but I'll share my understanding: Linux achieves low latency with real time interrupts -- several years ago Ingo Molnar created the first RT kernel patch for Linux. However, real time interrupts also, unfortunately, provide a vector for instability and insecurity, and BSD architecture intentionally disallows real-time interrupts to kernel space, from user space. Because of this, BSD latency is not low enough to allow for multitrack recording.

Re:Wht not sound?

[Freultwah]

Are you daft? Even the supported devices list from 2009 proves you wrong: http://manuals.opensound.com/devlists/Linux.html. In case you haven't been paying attention and are just trolling.

Isn't it a little late?

[mitzampt]

Coordinating with other engines? Isn't that the kind of thing that lets one use Wayland partially as a standalone server side to side to X? Is this the 'feature' of stepping down and letting other servers or engines develop?
Maybe we'll evolve this way past the Xorg.conf and its documentation, good riddance, moving from a wrinkled legacy to a more sane and friendly approach. I love X when it works, it's unbearable when it doesn't.

Brings as in it's now part of....

[Lumpy]

X has had multi touch for YEARS. It was a patch. it's only now that it's a part of the official.

Re:Why not sound?

[Anonymous Coward]

The X Consortium (the follow-on to the MIT X Consortium, i.e. the original x.org) started to do audio back around 1994.

Nobody gave a toss then and the project died when the consortium folded at the end of 1996.

And BTW, before that there were two competing audio extensions, one from DEC and the other from NCD IIRC, and neither one caught on.

Re:i thought xorg buried x a long time ago

[thopkins]

You are thinking of XFree86.

Does it only record multi-TOUCH events?

[mark-t]

Or can it also record things like multiple hovering events?

Re:Using X's power?

[Hatta]

Despite your dig at the command line, it really doesn't get any simpler than 'ssh -X remotehost remoteapp'.

Re:Wayland

[Anonymous Coward]

Wayland's current status: it continues to be the vaporware windowing system that is the darling of people who have no idea about what X really does or what its problems might be.

Re:Using X's power?

[Greyfox]

It's so not complicated to export a window to another display. Just set an environment variable to tell it where to display and authorize the machine on the remote display. Nothing to it. Despite that, the companies I've worked at that have needed to do this just set up VNC and work on the machine remotely instead.

If you want to do something like Sun, where you authenticate and it finds your session out there and pops it up on your machine, that's a bit more complicated. Pretty cool, but more complicated.

Its a pain to set up if you're an idiot

[Viol8]

"but it was a pain to set up and get it working."

Yup, I mean look at these examples for how devastatingly complicated it it:

"xterm -display [host ip]:[display id]"

or if you're feeling even more l337:

export DISPLAY=[host ip]:[display]
xterm

But I guess if you wet the bed at the thought of having to use a keyboard instead of a mouse then you're pretty screwed.

Re:Wayland

[celle]

"The UNIX world is becoming very Linux- and GNU-centric."

So much for being portable and flexible.

Re:Using X's power?

[rrohbeck]

I'm sure you can write a wrapper where you have to click at least a dozen times to select the remote host and app.