Pinos Is For Linux Video What PulseAudio Is For Audio

[ChristianSchaller]

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

[Ardje]

You mean pinos is to video recording what pulseaudio is to audio recording.... in a word, horrible.

Exactly what I thought....
If it was compared to jack, it might be a good tool, but professional audio applications either use alsa or jack, and always make clear to stay away from pa.

[DanL]

So apologize for those who felt I should have mentioned their favourite legacy audio server or mixing system... (also the announcement of Pinos wasn't meant to be a detailed history of Linux audio)

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:

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.

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

[tenente]

I don't know why my post didn't get through, but it's basicaly what DanL said.

I resumed it:
There's no complaining or angry post, just people remainding everyone that concurrency was there (and working well for dmix) and that it's not a new feature PA gave to linux audio. The skype guy story from an earlier post is though !

PS: anyway Good luck with Pinos.

[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".

[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.

[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.

[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.

[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.

[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