On Sat, May 14, 2011 at 07:29:01PM +0300, Sviatoslav Chagaev wrote: > On Mon, 9 May 2011 12:44:54 +0000 > Jacob Meuser <jake...@sdf.lonestar.org> wrote:
> > ok then, why do some devices have 'outputs.dac' yet others have > > 'inputs.dac'? what is the difference to the user? which is more > > correct? why? > > > > I have absolutely no idea. I'm not an audio equipment manufacturer. I > don't understand how are these questions even relevant. my point exactly. > > this has been the case since long before azalia(4). if you cannot > > explain this, then you just don't understand. you post a diff and assert that the class is the most important part of the name, but when confronted with an example of how the class is ambiguous, you cannot explain why. and it's not because you aren't a hardware manufacturer. I'm not a hardware mfg either. but I do work on OpenBSD's audio system. I have spent many, many hours reading the code, fixing issues, trying to figure out how to make things better. and I can confidently say that adding sorting to mixerctl is not the answer. in fact, that will make things worse, I guarantee it. > Suppose I have bought a new computer, can I predict where exactly these > controls will pop up in the output? all azalia(4) will have outputs.master very near the end. cannot say "exactly", as it depends on what controls the hardware supports. > > please do give an example of how sorting them makes "finding what you're > > looking for" easier. please. and it better be easier than piping > > through sort/grep. I'll repeat that you cannot rely on 'inputs' or > > 'outputs' having true meaning. sorry, but you can't. trust me on > > that one. > > > > Binary search. > I might not remember the exact name of the variable. > Why should I be suffering if someone has broken hardware? From all the > computers I owned -- there wasn't a single time when vars were labeled > incorrectly. > Even if I have broken hardware, I will know this the first time I use > it. No need to tell me that over and over again. This will not fix > my hardware. this is not an example, nor does it preclude using grep/sort. it's not about broken hardware. it's about inconsistent mixer(4) implementations, which is largely due to poor documentation of mixer(9). > It doesn't matter how mixerctl and other *ctl are _implemented_. They > should behave as similar as possible. I already showed how the *ctl programs do NOT behave similarly, even before you get to the listing of variables, if the *ctl programs even list variables. while I appreciate consistency, shooting yourself in the foot to be consistent is not a good idea. if you really want to fix the mixer(4) implementations, then you have to fix the mixer(4) implementations *in the low level drivers*. adding sorting in mixerctl will make that harder, because then the controls will not be in the same order as they are created by the drivers. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
