Re: ice1712 IPGA and ADC controls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Thu, 1 Feb 2007 10:10:31 +0000,
Alan Horstmann wrote:
> 
> 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)?

Hm?  The driver provides dB information, too, so the apps do know
easily what dB is...

>  Any 
> other recording app would leave the user unaware of what is happening.  Have 
> I grasped the proposals correctly?

If an app touches mixers for a certain purpose, it must know what
mixer elements play which role exactly.  How do you know whether the
"ABC Volume" is applied before "XYZ Volume" and after "QQQ Effect
Switch", and how this affects the output quality with each other?  The
really detailed adjustment cannot be done easily without a help of
dedicated application and external information.

OTOH, a generic mixer app must handle all mixer elements equally.
And, the problem is that most of mixer apps don't handle linked
controls correctly.

Anyway, I don't know of any recording apps that actually cope with
mixer volume elemtns of AK codecs.  (Note that these mixer elements
are unconvetional names.)  Let me know if I'm missing something.


Takashi

-------------------------------------------------------------------------
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

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux