Heya, >I need some suggestions! If you know something about this topic, please >comment. > >During development of my AC97 driver, I reviewed the available APIs. None >of them seems to be the "right" one. > >First there is the R3 one. It does not allow to add mixers that map >individual inputs, >like selection a "stereo mix of all active sound inputs" as a source. Only >4 predefined sources are available. There is also no way to add something >like a control for 3d enhancement. > >Next API I tried was the multiaudio API. I noticed that the documentation >allows >individaul mixer names. However, the mixer ioctls never get called, >and after reviewing the multi_audio.media_addon in /boot/beos/system/add-ons / >media >using "strings", "nm", and Diskprobe I had to realize that its not >implemented. >Also the API is fairly complex. > >There is a R4 api for mixer(gain ciontrol) and mux(connection selection), >but it does not seem to be documented, except by the driver >in /boot/optional/sample-code/drivers/sonic_vibes > >Dano introduced another API, called game audio, or whatever. > >Question: what should be our direction? Rewriting the multi audio api >media add-on, to support the currently missing functionality? >Dropping it (there are only two BeOS R5 drivers that seem to use it) >Documenting, extending the R4 API? >Simplifying the multiaudio API (I don't like the multi-buffer-exchange)? >Creating a new one? >Creating another, with a more streaming like approach? > >Requirements: It should be easy to write a driver that conforms to the API, >and it should provide low latencies. > >Please, send some suggestions... Well, my first thought is that we want to have for the first release the API that allows us to use the most drivers. I assume this is the R3 one? Then for the next release we work on our own API. I am guessing that the R4 and R5 API's have a low usage and so might be easier to ignore? So I suggest we get R3 API working, then build a better one. -- Cheers David Have you reconsidered a computer career?