On Tue, 23.09.08 09:26, Alan Cox (alan@xxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
