On Sat, Jun 09, 2012 at 07:00:19PM +0200, Antoine Jacoutot wrote: > 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...
This is true only for very small programs. Making the program build is only part of the work. What if the program doesn't work very well, say audio stutters? You have to fix it, and debugging timing bugs is a nightmare. Experience has shown that it's easier to write sndio backends than to debug timing bugs or deal with subtle differences between API implementations, or subtle timing differences in the behavior. AFAICT, this was explained several times by jakemsr@ who ported a lot of audio programs to OpenBSD. In other words, having $RANDOM_LINUX_API might save porting time only for trivial players, but would make us spend more time on the average audio program. And I understand very well your frustration. I know that you can't just type "./configure && make" to build linux apps, and this difference seems gratuitous. But it isn't. This is best we could do. And I believe it was the right choice. > 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. OSS compat glue doesn't work very well. It would help you compile linux programs but you would spend more time if you want programs to work well. And we already have OSS compat glue that has proven that compat glue doesn't help, except for trivial code. While it brings more problems. > 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. So what do you prefer? learn the OSS API to be able to debug timing issues & stuttering? or learn sndio, which is order of magnitude simpler. And same here, I wish I had 48h days to finish my stuff and help with porting. > > 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. > Sorry, my bad. I misunderstood your point. > > 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? Mainly for audio centric technical reasons. To ease porting of audio programs was one of the them. Again by "porting" I mean make programs work without stuttering, not just build. > 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?). Technically, OSS and SUN are kernel-based so they prevent us from moving audio stack out of the kernel and moving forward. So they don't do the job. Futhermore they are very error-prone and hard to use for full-duplex programs. Audio is inherently simple and deserves a simple api. ALSA is very good to my opinion. But it's too complex, and we wouldn't be able to get the code right, in turn causing ports to not work or to require subtle hacks. Which would require porters to learn ALSA. > > 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? AFAICS, writing/porting a simple mixer GUI to control the volume is less work than porting pulseaudio. -- Alexandre
