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
Announcement
Collapse
No announcement yet.
Pinos Is For Linux Video What PulseAudio Is For Audio
Collapse
X
-
Originally posted by rabcor View PostYou mean pinos is to video recording what pulseaudio is to audio recording.... in a word, horrible.
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.
Comment
-
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)
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.
Comment
-
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.
Comment
-
Originally posted by DanL View PostYou'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...
Comment
-
Originally posted by ChristianSchaller View PostHeh, 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
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.Last edited by duby229; 01 July 2015, 10:08 AM.
Comment
-
Originally posted by Ancurio View Post
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.
Comment
-
Originally posted by psychoticmeow View Postwho blows "properly fixed that" up into "the only thing that ever attempted to fix that".
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 trollLast edited by DanL; 01 July 2015, 10:35 AM.
Comment
-
Originally posted by duby229 View Post
That's not how it works. The CPU uses a hell of a lot more power than an AC97 codec.
Comment
-
Originally posted by Ancurio View Post
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.
Last edited by duby229; 01 July 2015, 11:23 AM.
Comment
Comment