On Tuesday 30 January 2007 11:14, Takashi Iwai wrote: > At Tue, 30 Jan 2007 06:18:38 +0000 (UTC), > > Tim wrote: > > > > There is no such thing as analog attenuation on these chips. > > Only an analog gain stage from 0db to +18, followed by a digital > > attenuation stage from 0db down to infinity (mute). > > Both of these functions are accessed through the same register, > > as a continous range from 0 to 164. The first 127 steps > > 'activate' the digital attenuator, with 127 being 0db, while the > > last 37 steps 'activate' the analog gain. > > In other words, from 0-127 ONLY the digital attenuation stage is > > activated. From 128 to 164, ONLY the analog gain stage is activated. Agreed correct so far. > > It was intended to be one control. I don't accept that assertion, though only AKM know their intentions. I still maintain it is 2 functions combined into a single register -like a composite video signal; if the signal goes >0.3V it is video, whereas <0.3V it is a sync pulse. That doesn't mean sync and video are the same. In the AKM convertor case, we need to look at the functions being controlled not at the registers to understand the significance of each part. Hence I see 2 separate features of the convertor chip. This discussion is frustrating because we have not started from the position of designing the capture system, starting with the signal path, then the digital control logic and then specifying how the software should operate it. It seems rather a case here of the software 'tail' wagging the 'high-resolution-capture-system' dog. But while manufacturers don't express their design intentions with drivers for linux, this is where we are left. > > Anyways, I say we add some type of 'decorations' to envy24control. > > Some type of markings. Two end-to-end 'braces' along the side spanning > > the length of sliders, one labeled "digital att." meaning that the range > > from 0-127 is digital attenuation, and the other labeled "analog gain" > > meaning the range 127-164 is analog gain. It would be a great visual > > reminder of this underlying technical detail we have discussed here, so > > everyone should understand it. > > And of course all values in db's as well as integers. > > Yes. It's the way to go, IMO. > Make the API simple. Improve the usability in another part. > > A question from usability viewpoint is what is the good way to handle > two linked volumes. For example, > > 1) two volume bars can be changed at any time. If one of them is > changed, another is automatically set (jumps) to zero. > 2) when one volume is set to non-zero, another is visiblly disabled. > to zero and cannot be changed. Once after both are set to zero, > both become accessible. > > I think the latter is less confusing, at least. The jump of volume > bar always annoyed me. Two controls interlinked worked fine for me -perhaps because I understand why? I think any scheme should provide a quick way to get to that 0dB position, which is one other reason I don't like a single combined fader. Trying to set 127 not 126 or 128 in the mid-range with mouse movement is tricky, compared to simply pulling the control to max or min. Terratec for example implement the analogue gain as a rotary control above the channel fader. If the driver provides only a single control, then would envy24control be the only mixer to make the user aware of the dual function, and to make the 0dB point accessible (whether by marking one control or splitting to two)? Any other recording app would leave the user unaware of what is happening. Have I grasped the proposals correctly? Alan ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
