Pinos Is For Linux Video What PulseAudio Is For Audio

[tenente]

psychoticmeow are you turning trolling mode ?
One of the first sentence on the blog is:
"For those of you who has been around for a while you might remember how you once upon a time could only have one application using the sound card at the same time until PulseAudio properly fixed that."

DanL is thus not meaning something other than what the author intended. he is just paraphrasing. The sentence meaning is clear, there was no solution for concurrency before PA, which is false. ChristianSchaller admited it himself !
He still thought that everyone not using PA is an idiot and he is quite condescending in his post but that's none of my business.

[duby229]

You need to read a lot more. Ancurio is absolutely right, even if low on details, and it doesn't boil down to simple context switching.

Read this: http://0pointer.de/blog/projects/pulse-glitch-free.html

Now, PA might not be perfect, but you must remember it still runs on top of ALSA, so if your ALSA driver is misbehaving, so will PA. And no, the possibility that other apps run fine on top of ALSA and bad on top of PA doesn't mean it's PA's fault, since PA might be using another codepath of your driver.

Back on topic, I currently don't have a need for Pinos, but it sure seems like it solves a problem people may encounter, so why not?

Sorry man but a liar is a liar. LP has spewed so much crap from his mouth there is absolutely nothing that can clean it. There is zero words in that article that can be trusted. In fact I'd be willing to wager that a code audit would prove most of what he said there as lies.

[psychoticmeow]

Uhh, no. The key part of the statement is "once upon a time could only have one application using the sound card at the same time", could only meaning "unable to" in this instance, which is false.
Were the solutions that came before PulseAudio perfect? No.
Was PulseAudio ever perfect? No.
Was/is Pulseaudio better than those solutions (either then or now)? Maybe. You've obviously got people who would argue either way. Still, that's a tired old debate and it's not relevant here. Even if the author believes it is/was better, that's not what he said or implied.


If your reading comprehension sucks that much, you shouldn't be calling people such names. Do the world a favor and unplug your keyboard. Either throw it away or use it to beat some sense into your head before you plug it back in.

Yelling at me about my reading comprehension when you've just taken a fair generalisation to mean something other than what the author intended.

[mdias]

What you're talking about boils down to context switching. And yeah it is a good idea to avoid that, but keeping the cpu busy isn't a good way to it. A busy CPU isn't the answer.

http://wiki.osdev.org/Context_Switching

You need to read a lot more. Ancurio is absolutely right, even if low on details, and it doesn't boil down to simple context switching.

Read this: http://0pointer.de/blog/projects/pulse-glitch-free.html

Now, PA might not be perfect, but you must remember it still runs on top of ALSA, so if your ALSA driver is misbehaving, so will PA. And no, the possibility that other apps run fine on top of ALSA and bad on top of PA doesn't mean it's PA's fault, since PA might be using another codepath of your driver.

Back on topic, I currently don't have a need for Pinos, but it sure seems like it solves a problem people may encounter, so why not?

[duby229]

If you want audio to play, you have to write to some ringbuffer on your audio card. The smaller the chunks you write in, the lower the latency, and the higher the amount of times your CPU has to wake up to write new data. That's my understanding of it at least.

What you're talking about boils down to context switching. And yeah it is a good idea to avoid that, but keeping the cpu busy isn't a good way to it. A busy CPU isn't the answer.

http://wiki.osdev.org/Context_Switching

[Ancurio]

That's not how it works. The CPU uses a hell of a lot more power than an AC97 codec.

If you want audio to play, you have to write to some ringbuffer on your audio card. The smaller the chunks you write in, the lower the latency, and the higher the amount of times your CPU has to wake up to write new data. That's my understanding of it at least.

[DanL]

who blows "properly fixed that" up into "the only thing that ever attempted to fix that".

Uhh, no. The key part of the statement is "once upon a time could only have one application using the sound card at the same time", could only meaning "unable to" in this instance, which is false.
Were the solutions that came before PulseAudio perfect? No.
Was PulseAudio ever perfect? No.
Was/is Pulseaudio better than those solutions (either then or now)? Maybe. You've obviously got people who would argue either way. Still, that's a tired old debate and it's not relevant here. Even if the author believes it is/was better, that's not what he said or implied.

Or you could just not be a nit-picking troll

If your reading comprehension sucks that much, you shouldn't be calling people such names. Do the world a favor and unplug your keyboard. Either throw it away or use it to beat some sense into your head before you plug it back in.

[duby229]

From what I remember, PulseAudio, by design, tries to go for as much latency as possible, unless the app specifically requests a lower value. It's not possible to flat out say "latency is bad", because it's simply a trade-off. If you want to go for minimal latency, you will incur maximum energy consumption. If you want to minimize energy consumption, you have to ramp up latency.

Seeing as most casual PC and laptop users have little need for ultra-low latency, but would greatly appreciate low energy consumption, I think PA has made the best choice it could.

That's not how it works. The CPU uses a hell of a lot more power than an AC97 codec.

[duby229]

Heh, some angry posts on here Anyway, I see some comments complaining that I didn't mention that there was/is other alternatives to PulseAudio like dmix, artsd, esd and so on. And true enough those systems was around, but in my opinion those systems all had various issues and it wasn't until PulseAudio came around that we had something that worked well enough to establish itself as the standard and fix it generally enough to really solve the issues. So yes there was many attempts to solve the problems we had with audio back in the day, but PA was the only one good enough to stick. So apologize for those who felt I should have mentioned their favourite legacy audio server or mixing system, but to me the issue only truly got fixed once PA came to be and thus my wording (also the announcement of Pinos wasn't meant to be a detailed history of Linux audio

Yeah, sorry about that. Please don't take any offense. It's not anything about your software. It's just that immediately a parallel was made with PA, and many people hate that garbage. If that parallel hadn't been made then I don't think it would of have happened that way.

The aren't any valid use cases for ultra high latency, high cpu usage audio servers. People can defend it all they want, but they are all flat out wrong.

EDIT: A 25mhz 486sx without a 387 could playback audio. It's not like audio is a monster job.

[psychoticmeow]

You're missing the point. No one expected you to give a history of software mixing, or cares if you didn't mention Pulseaudio alternatives in a blog post about Pinos. The point is that your statement is simplified to the point where it's false. It's ignorance (at best) or a flat-out lie.

Try this: "Pulseaudio allows you to share sound devices between multiple applications."
Instead of:

That way, you don't have revisionist/false history...

Or you could just not be a nit-picking troll who blows "properly fixed that" up into "the only thing that ever attempted to fix that".