On Fri, 28 Jul 2006 12:04:28 -0700 (PDT) Bill Unruh <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Jul 2006, Sergei Steshenko wrote: > > > On Fri, 28 Jul 2006 11:07:51 -0400 > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > >> On Fri, 2006-07-28 at 12:47 +0200, Eduard Bloch wrote: > >>> Yes, I talk about useability which just sucks. I imagine a more clear > >>> frontend/backend infrastructure, an ultimate solution: > >>> > >>> - access to all backend settings is exported with consistent, fixed > >>> names > >>> (keywords) > >>> - a wrapper in the library has a database of sound cards and of > >>> applicability of particular controls to it > >>> - an UI control layer would have a database of possible > >>> "end-user-to-control-setting" wrapper. There may be different > >>> schemes > >>> of such kind, where compatibility with drivers is documented as > >>> well. > >>> - HMI related issues like the grouping hints for the particular > >>> controls in the schemes, the kind of control (binary/discrete/ > >>> stepless) > >> > >> Probably impossible to implement without full hardware specs for all > >> supported cards. > >> > >> Lee > >> > >> > > > > If you, the developers, have already written the driver and know > > how it works, what hardware specs do you need ? > > So you know how the drivers are written? They get some card, which the > manufacturer refuses to tell them anything about. The manufacturer will > even claim that the dimensions of the card ( which you can measure with a > ruler) are a trade secret which they will not divulge to you. Eg, Maudio > refused to tell me which of the files in theirs Windows disk was the > firmware for their card. This they said was a trade secret, a trade secret > which was revealed by looking in the .inf file.) They then > take that card and the windows drivers and try to figure out how the hell > it works. They manage, but and write a driver with their knowledge, but > they are never sure that under some situations the card will not behave as > they thought it did from their study. Or there are features they are simply > unable to figure out by the above procedure. > > So NO. Having written a driver does NOT mean that they know how it works. > They simply know enough to write the driver and it seems to work. > > > > > It's the documentation issue and/or HAL issue. The guy expresses my > > thoughts very well. > > > > I'm glad yet another end user speaks out about ALSA user friendliness. > > Alsa does leave something to be desired on the documentation level. However > this is largely because they are wasting huge amounts of their time trying > to figure out what the hell these new cards are doing and how they do it, > when a brief note from the manufacturers would save weeks of time. > > Now if you want to volunteer writing documentation, and are competent at > it, I am sure that the alsa people would be more than happy to give you the > job. > > > > > > > What I know, is that when I bought M-Audio Revoluion 7.1 - fully supported by ALSA, I couldn't make "capture loopback" work - documentation said nothing on it. After filing a bug I did, eventually. got an explanation from the developers how to make it work. No patch/code change was necessary - just certain combination of mixer controls. This means: 1) developers DID know how to make this feature work; 2( developers DID NOT bother to write the documentation. Regarding writing the documentation - as I said, the developers are the ones who are intimately familiar with the driver internals control functionality. My logic is simple: * if you are saying that a feature is supported, this means you've tested it - otherwise you are simply irresponsible. * if you have tested it, this means you EXACTLY know what controls should be set to what values to make the feature work; * what you, developers, apparently are not doing, is that you are not writing down the controls while the features are tested. Had you written down the controls per feature tested and had you published these records, there would have been much smaller frustration on end users side regarding ALSA. Sorry guys, I was taught to write down my action way back in the USSR, at a high school with emphasis on physics and mathematics, in the course of physics labs. That is, I acquired the "write down" knowledge/approach at the age of 14. I do release documentation for the projects I release and expect the same from ALSA (and any other FOSS project for that matter). -- Visit my http://appsfromscratch.berlios.de/ open source project. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
