Getting rid of pulseaudio? [was Re: Cannot play MP3 or OGG as ringtone on GTA02]

Joerg Reisenweber joerg at openmoko.org
Sat Jul 26 00:54:16 CEST 2008


Am Sa  26. Juli 2008 schrieb Joachim Steiger:
> > Am Dienstag 22 Juli 2008 03:19:24 schrieb Russell Sears:
> >> Michael 'Mickey' Lauer wrote:
> > Well, pulseaudio is great. Honestly, I love the concept, that's why I 
pushed 
> > it in to Openmoko in the first place. But alas, the current state is way 
> > unusable on our slow systems. Perhaps this will improve with the new 
branch, 
> > lets see. Until then, it's alsa dmix for me.
> 
> i agree. pulse needs to get better first.
> still, dmix will bite us in the ass on the long run, since it has no
> concept of anything but static buffers, 
> can nor handle fullduplex audio, 

HUH?


> or stream routing (its alsa after all).
> means moving playing audio from the bt headset to the line-out will
> never be possible with alsa only.

That's correct. The app can assume the audio device to stay. If we want to 
change it, app has to do this by closing the one device and opening another 
one.

> 
> doesn't matter. still enough other stuff to get working first, and in
> the end your apps should only use highlevel interfaces,

Hmm, what might this be, other than a device open() for alsa e.g. ?
Are there more high-level'ish concepts to push out raw 16bit audio data, than 
having a handle and do some write() on it?


> and not need to 
> tamper with alsa-interfaces anyways. so it is transparent and your app
> will do the same calls, regardless which underlying backend.
> 
> >> Also, is GStreamer definitely in the future?  I'm looking into
> >> fixed-point graphic equalizers; gstreamer seems to be a good place to
> >> add one.
> > 
> > Absolutely. GStreamer is great and will be a vital part of the Openmoko 
> > framework.
> 
> ack ;)
> 
> >> The choices for adding new audio processing code seem to be adding a
> >> plugin to gstreamer, alsa or pulseaudio.
> > 
> > If you want to maximize performance, go alsa. If you want to maximize 
reusing, 
> > go GStreamer.
> > 
> 
> since alsa is hw-abstraction only, not stream routing,
hmmm...

> not stream 
> processing (besides of in and output) 
besides of ladspa plugins, resampling, mixing, level adjust, storing to 
files... Sounds like stream processing to me

> and doesn't have any sane 
> framework for stuff like equalizers (or any software based signal
> processing)
see above

> i would recommend gstreamer for that. 
conclusion ok, rationale weak.

> 
> alsa should stay what it is. a driver framework.
> adding more layering violations doesn't help (and would hinder pushing
> stuff upstream in the long run)
Again, hmmm....

/jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/support/attachments/20080726/7249170b/attachment.pgp 


More information about the support mailing list