Pulseaudio : lots of issues, how can I help?

[Lennart Poettering]

On Tue, 23.09.08 09:26, Alan Cox (alan at redhat.com) wrote:

> 
> On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
> > OTOH OSS' programmers interface *is* the ioctls themselves. And that's
> > one reason why its API sucks.
> 
> Thats a 'nobody wrote the library' case

No it's not. The people behind OSS (i.e. Hannu) advertise the kernel
API is the audio API to use for normal programs. Because they do this
they moved mixing and sample type conversion into the kernel in OSS4.

> > Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
> > hacks, that only work for the smallest part) The timing model is
> > broken. The entire design is hardware-specific, and focusses on hw we
> 
> The timing model is crap, but the rest of the design is neither hardware
> specific no focussed on twenty year old hardware - in fact todays hardware
> looks more and more like the hardware of twenty years ago but with more
> channels.

Oh, of course it is hardware specific. Stuff like fragments and stuff
are very hardware specific. Software sound servers don't want to
expose fragment-based buffering metrics. Instead a modern sound system
wants to expose latency values and process time values. Then, the fact
that OSS assumes that the DAC reads directly from the hw playback
buffer makes the whole thing questionable already on USB
hardware. That you even get access to the hardware buffer makes it
very hardware-specific. Using OSS for more than 2ch sensibly is
practically not possible. Modern sound systems want to disable sound
card interrupts as far as possible and schedule audio via system
timers, OSS always wants fragment interrupts. Modern sound systems
want huge buffers and the ability to rewind software pointers. OSS
cannot do this (at most partially if you use mmap() which opens a lot
of additional problems and is shaky ground). No decibel information
for mixers. Then, the way fragments work in OSS you couldn't even
express something like "buffer size 200ms, fillup when only 10ms
left". And this list goes on and on.

In short: how modern software wants to drive a sound card has changed
quite a bit. And OSS3 is from the early 90's. So it's focussed on
hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
quite different from a modern HDA sound card.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4