On Sat, Jun 09, 2012 at 04:00:27PM +0200, Alexandre Ratchov wrote: > On Fri, Jun 08, 2012 at 10:39:16AM +0200, Antoine Jacoutot wrote: > > > If you want to try it and have sndio diffs to review, fix, etc... > > > don't hesitate. I'm not against pulse; it's just very low in my > > > todo list. > > > > I don't know anyone in the project able to do that but you (and > > jakemsr but he's gone now). > > > > Come on, there are sndio backends written by others as well, the > API is simple and it's documented. But that's not the point.
It _is_ the point. And I already discussed with you several times privately in the past about how this is exactly the point. One cannot expect to know all the APIs around; when I compile something that requires X libraries I don't need to know much about the X API; if I compile something --with-ssl I don't need to be familiar withe the openssl API (thank god!). With sndio each time an application deals with audio (whether it's big like pulse or a small one), then it needs to be ported over which may not be trivial and requires audio knowledge. Look how long people have been trying to port chromium over to sndio without success... So far sndio has changed nothing to me as a regular user but has been nothing but pain as a porter. I having nothing per se against it, I'm sure it 's not a nih syndrom and does fullfil some needs for you audio gurus. When you first discussed about adding this new audio API several years ago one of the first thing I asked you guys was to think about some compatibility glue with e.g. OSS to leverage the work for porters. And I repeatedly talk to you everynow and then about it. I already spends a huge amount of time on ports, for myself, by helping people, by reviewing stuffs, by working on the infrastructure to ease my fellow porters'work... I think I already share a large burden on the ports maintainance; I wish I had 48h days to learn new APIs all the time, but I don't. > The point is that you can't ask me to postpone fixing other audio > stuff in order to work on software I don't use. Especially after > I've told you that I don't think it would work very well. I have never requested that _you_ do this. > If you think it would work well enough for you, or just want to try > it then write a sndio backend for pulse. I'll be there to help > debugging stuff, explaining parts of the API that are not clear, > etc. > > [...] > > As we're at it, a more general note: we're a small community; we > don't have full-time developpers working on fashionable software. Exactly, so why are we forced to be uncompatible with everyone else? There are already many places where we defer from the majority of Unices (for good reason, I'm not complaining here) but audio should be something that should just work by respecting some sort of standard. Not "official" standard, but the pragmatic one, that is the one most people use and expect so be available on a system (OSS? ALSA? SUN?). > IMHO, having a small set of quality programs that cover all > use-cases is more realistic than supporting everything that exists. > Spending a lot of time on tons of programs with duplicate > funtionalty won't bring us quality. I don't want to cover all use cases, I just want to be able to have audio and mixer controls on my desktop, or is that a use case that is too unrealistic? -- Antoine
