Skip to main content

<i>if phonon-gstreamer dropped support for ALSA and OSS, and forced everyone ...



- 2012-05-17T06:56:35+0000 - Updated: 2012-05-17T06:56:35+0000
if phonon-gstreamer dropped support for ALSA and OSS, and forced everyone to use pulseaudio

Musings on the linux audio stack |

Shared with: Public, Tomasz Torcz, Daniel Horecki
- 2012-05-17T11:37:57+0000
Which is actually a good suggestion - problem with Linux audio is that there are too many connections in the graph of audio stack components.
- 2012-05-17T13:30:55+0000
But pulseaudio is using ALSA anyway, so where is gain?
- 2012-05-17T13:36:30+0000 - Updated: 2012-05-17T13:37:35+0000
+Daniel Horecki Sane API, less than hundred different combinations to test, friendly upstream...
And PA gives more than what's supported in ALSA (Bluetooth audio comes to mind).
- 2012-05-17T13:37:03+0000
Unification. Right now we can have different applications accessing audio hardware in different ways - some directly access drivers via ALSA or OSS, others use Pulseaudio, or JACK, or whatever.
- 2012-05-17T13:40:39+0000
+Tomasz Torcz On the other hand, is there any way to marry PulseAudio with JACK in a usable way?
- 2012-05-17T13:40:52+0000
No, they serve different purposes. That's why PA yields device when Jack asks for it.
- 2012-05-17T13:45:17+0000 - Updated: 2012-05-17T13:45:51+0000
I wonder what was wrong with reading how JACK works and simply reusing same method in PulseAudio to achieve low and constant delays.
- 2012-05-17T13:50:46+0000 - Updated: 2012-05-17T13:52:14+0000
As I see, Jack generates fuckloads of interrupts, waking CPU and draining battery. PA in optimal cases let CPU sleep for few seconds between wakeups.
And http://0pointer.de/blog/projects/when-pa-and-when-not.html

Comments


Comments powered by Disqus