Canonical Shows Mir, Unity-Next Running On MacBook Pro

[Teho]

PA is not fine for most people. Give me one good reason why most people should have to deal with massive audio lag. There isnt one.

The only people who need to deal with massive audio lag are the ones with broken drivers. I haven't had any problem with PulseAudio latency in any of the computers I have owned or tried for example. The people who have problems with PulseAudio are in a small minority, otherwise it wouldn't have been used in virtually every Linux distribution by default for years.

[duby229]

The internet exists. Free flow of information. Just google PA lag. There are literally tens of thousands of hits.

I have a cmedia 8770 which has awesome drivers that work flawlessly. But PA gives me latency measured in seconds. All of it from the PA stack. None of it from the ALSA stack.

The -ONLY- reason PA is default on so many machines is because of arrogance. "Fuck bug reports. If it works for me then it -WILL- work for everyone else because ---I--- said so DAMN IT!!"

I've heard it a million times and your last post is just one more to add to list.

[Teho]

The internet exists. Free flow of information. Just google PA lag. There are literally tens of thousands of hits.

There are literally tens of millions of Linux users. Also the bug reports represent time span of five years or so. The start was rough for various reasons, including bad driver support that has been for the most part fixed by now. Even from the start most people would be fine with PulseAudio but the number of people with issues was notable; not anymore.

I have a cmedia 8770 which has awesome drivers that work flawlessly. But PA gives me latency measured in seconds. All of it from the PA stack. None of it from the ALSA stack.

It has awesome drivers that in all likehood report false timing information.

The -ONLY- reason PA is default on so many machines is because of arrogance. "Fuck bug reports. If it works for me then it -WILL- work for everyone else because ---I--- said so DAMN IT!!"

Yes because none of the distribution maintainers know what they are doing... There's no solution that works for everyone; PulseAudio is the one that fills the needs of most people and that's also what most distributions are trying to do.

[zester]

It's completely irrelevant (for me anyway) until someone actually builds an easily set up and usable stack that applications support. PulseAudio is great for consumer audio in a sense that it has decent graphical mixers (Veromix for example), it's power efficient, it has good support for stuff like bluetooth headsets and other hotplugged devices like USB soundcards and such and has support for easy configuration of audio channels (like changing audio output of an applications without a pause, easily configuring output from multiple applications to multiple different outputs and so on...). Jack for example doesn't concern itself with power usage (the literal one) and being easy for "normal" usecases (it shouldn't need any configuration); the performance benefits are irrelevant for pretty much anything else but audio production. Sure it would be nice to have single system that covers both cases but such thing doesn't exist nor does Jack or PulseAudio intend to be one.

You listed the file types in some of the user folders; would the idea be for the system to automatically sort the files or something?

...and wow, that's a lot of projects. In any case it would be nice to see some of those projects to mature to point of being ready for general consumption.

I cant really comment on the first part of your post, I fully understand where your coming from. I really do. I am looking at not only RtAudio but stuff like ...

1. Hardware Detection (pyudev)
2. Parsing and Writing Kernel Config's (Kconfiglib "Python")
....

Looking for away to not only be able to easily interface but also configure every supported device. But in general the idea might be that pyudev could detect the your hardware
in this case post system install, and write the kernel config and recompile the kernel. This might only have performance improvements but who knows. I haven't gotten far enough
with hardware detection other than stage 2 of what the OpenSuse Install can do in-regards.

There are also other core libs like libusb and pciutils, .....


The filetypes in some of the folders, I think at the time. Its been awhile since I last looked at it was to sort files in the Download folder and move stuff to its proper location. I think I was being OCD that day who knows.

But the custom filesystem in general will not be easy, from what I am told glibc hard codes some paths on linux (/etc dir)? I would have to do some googling to find the actual topic. I think its on the
http://www.musl-libc.org/ mailing list.

[duby229]

Yes because none of the distribution maintainers know what they are doing... There's no solution that works for everyone; PulseAudio is the one that fills the needs of most people and that's also what most distributions are trying to do.

See.... a.k.a...

"Fuck bug reports. It's -going- to work for you because -I- said so...."

Thats the usual response.

[zester]

See.... a.k.a...

"Fuck bug reports. It's -going- to work for you because -I- said so...."

Thats the usual response.

HeeHee or you develop a feature for an application, but because your not apart of the "in crowd", not only will they not even look at the code but reject it because apparently that's not a direction there interested in taking. Then two months down the line that feature is announced and its all thanks to "Johnny Blowjob".

Yup been there done that.

[Redshirt001]

PA is not fine for most people. Give me one good reason why most people should have to deal with massive audio lag. There isnt one. Exactly why should most people have to listen to skips and pops in their applications? Why? How -exactly- do you justify that as being fine for most people?

EDIT: That's kind of arrogant to put that on most people don't you think? Wouldnt it be better then to NOT put that on most people?

EDIT2: And if you agree with me that it would be better to not put that on most people, then wouldnt it be better to NOT use PA?

Firstly, I do not get noticeable lag with pulseaudio at all. Ever. Not in years. Secondly, I do get the occasional audio glitch in pulseaudio, but it's mostly with wine games, which does not have specific support for pulseaudio, despite repeated requests. Third, pulseaudio is more than fine for my usage, I'm just a desktop linux user with no special needs like audio work, and if I did need that, I know very well that I'd need an alternative. But it would be either installed alongside what is already on my ubuntu system, or on an alternate system set aside for that work. Needless hate for pulseaudio, and totally irrelevant to the article we are supposedly commenting on. Way to get sidetracked, all.

[Kivada]

I hate to be the one to break this to you, but it isn't going to be too much longer before AMD starts manufacturing ARM chips -for- enthusiasts like us. I for one am excited and can't wait for that day. It is about damn time that we as an industry moved away from x86.

Arm isn't going to be there on performance for years to come, the ARM chips AMD would be producing would be ones for low performance servers with a very high energy efficiency.

They'll be more like these http://liliputing.com/2011/03/480-co...n-the-way.html then anything on the desktop. Which would be great for hosting a bunch of web and mail servers that don't get allot of traffic. The performance per watt would suck for most tasks though, OpenCL would work ok on them, but a fast GPU would be faster. They could be decent at ray tracing though.

[dee.]

Arm isn't going to be there on performance for years to come, the ARM chips AMD would be producing would be ones for low performance servers with a very high energy efficiency.

They'll be more like these http://liliputing.com/2011/03/480-co...n-the-way.html then anything on the desktop. Which would be great for hosting a bunch of web and mail servers that don't get allot of traffic. The performance per watt would suck for most tasks though, OpenCL would work ok on them, but a fast GPU would be faster. They could be decent at ray tracing though.

Did you know there are already 64-bit ARMv8 CPUs available for servers?

http://www.anandtech.com/show/5098/applied-micros-xgene-the-first-armv8-soc

[pandev92]

I can definitely agree with the Jack comment, but I don't like PulseAudio at all.

I hate jack, is a piece of shit in my pc