Need help: My .asoundrc no longer works.

Need help: My .asoundrc no longer works.

[Tim]

Thanks for the emu patch! Works ok now.

Now I have a problem I reeeeeally need help with.
I have an SBLive! (emu10k1) as card 0 and an 
 M-audio Delta1010LT (ice1712) as card 1.
With alsa-1.0.9 the following .asoundrc files worked OK.

But now I've installed Mandriva2007 (alsa-1.0.12).
What happens now is this: QJackCtl presents me with 
 16 inputs, as before, but only the lower eight emu10k1 
 ones give me any audio. I get no audio by connecting 
 any of the upper eight ice1712 inputs to ANY of the 
 (twelve hw:1,0) outputs.
If I reverse the order of the cards in .asoundrc - see below,
 (ie lower eight inputs ice1712, upper eight emu10k1),
 then STILL only the LOWER eight QJackCtl inputs work -
 which are the ice1712 inputs !

But if I interleave the inputs - see third .asoundrc below,
 (ie one emu input, then one ice input, then one emu etc.),
 strangely only the emu inputs work, not the ice inputs !

Note the single use of a plug converter. This is the only way
 I can make them work, converting the emu but not the ice gives 
 'no playback configs avail', and converting both emu and ice gives
 ALSA: could not complete read of 0 frames: error = -32
 cycle execution failure, exiting
 DRIVER NT: could not run driver cycle.

At first I though maybe a pcm multi problem. 
I looked at changes to pcm_multi.c, not much change there, but I 'reverted'
 a couple of things back to 1.0.9 state, but it didn't fix the problem.

Anyway, since the problem is always with the 'b' slave,
 and since the 'b' slave always needs a converter, I'm wondering
 if there's a problem with the 'plug' converter itself (or my plug sections).

Any help much appreciated! Thanks. 
I hope this can be fixed - many hours I've just spent, getting
 this new distro (fixed) up - only to reach this conclusion now!
Cheers. Tim. 


----------------------------------------------------
Original .asoundrc with emu10k1 ahead of ice1712:
----------------------------------------------------
pcm.ice1712 {
              type hw
              card 1
            }

pcm_slave.sl3 {
    pcm ice1712
}

pcm.ice1712_convert {
    type plug
    slave sl3
}

pcm.multi_rec {
            type multi;
            slaves.a.pcm "hw:0,2";
            slaves.a.channels 16;
            slaves.b.pcm ice1712_convert;
            slaves.b.channels 8;
            
            # Some SBLive! inputs.
            # Customized emu10k1 driver gives me EIGHT seperate
            #  MIDI SoundFont audio inputs, rather than just
            #  combining them ALL on TWO FX lines !!!
            # Ask me, if you're wondering about this.
            # I may ask YOU later to include this feature in alsa !
            bindings.0.slave a;
            bindings.0.channel 10;
            bindings.1.slave a;
            bindings.1.channel 11;
            bindings.2.slave a;
            bindings.2.channel 12;
            bindings.3.slave a;
            bindings.3.channel 13;
            
            bindings.4.slave a;
            bindings.4.channel 14;
            bindings.5.slave a;
            bindings.5.channel 15;
            bindings.6.slave a;
            bindings.6.channel 0;
            bindings.7.slave a;
            bindings.7.channel 1;
            
            #
            # M-audio delta1010LT
            #
            bindings.8.slave b;
            bindings.8.channel 0;
            bindings.9.slave b;
            bindings.9.channel 1;
            bindings.10.slave b;
            bindings.10.channel 2;
            bindings.11.slave b;
            bindings.11.channel 3;
          
            bindings.12.slave b;
            bindings.12.channel 4;
            bindings.13.slave b;
            bindings.13.channel 5;
            bindings.14.slave b;
            bindings.14.channel 6;
            bindings.15.slave b;
            bindings.15.channel 7;
          }

ctl.multi_rec {
            type hw;
            card 0;
          }



-----------------------------------------------
.asoundrc with ice1712 ahead of emu10k1
-----------------------------------------------
pcm.emu10k1_multi_rec {
              type hw
              card 0
              device 2
            }

pcm_slave.sl2 {
    pcm emu10k1_multi_rec
}

pcm.emu10k1_convert_rec {
    type plug
    slave sl2
}

pcm.multi_rec {
            type multi;
            slaves.a.pcm "hw:1,0";
            slaves.a.channels 8;
            slaves.b.pcm emu10k1_convert_rec;
            slaves.b.channels 16;
            
            #
            # M-audio delta1010LT
            #
            bindings.0.slave a;
            bindings.0.channel 0;
            bindings.1.slave a;
            bindings.1.channel 1;
            bindings.2.slave a;
            bindings.2.channel 2;
            bindings.3.slave a;
            bindings.3.channel 3;
          
            bindings.4.slave a;
            bindings.4.channel 4;
            bindings.5.slave a;
            bindings.5.channel 5;
            bindings.6.slave a;
            bindings.6.channel 6;
            bindings.7.slave a;
            bindings.7.channel 7;
            
            # Eight SBLive! inputs. See comments in the other .asoundrc
            bindings.8.slave b;
            bindings.8.channel 10;
            bindings.9.slave b;
            bindings.9.channel 11;
            bindings.10.slave b;
            bindings.10.channel 12;
            bindings.11.slave b;
            bindings.11.channel 13;
            
            bindings.12.slave b;
            bindings.12.channel 14;
            bindings.13.slave b;
            bindings.13.channel 15;
            bindings.14.slave b;
            bindings.14.channel 0;
            bindings.15.slave b;
            bindings.15.channel 1;
          }

ctl.multi_rec {
            type hw;
            card 0;
          }



------------------------------------------------------
.asoundrc with emu10k1 interleaved with ice1712:
------------------------------------------------------
pcm.ice1712 {
              type hw
              card 1
            }

pcm_slave.sl3 {
    pcm ice1712
}

pcm.ice1712_convert {
    type plug
    slave sl3
}

pcm.multi_rec {
            type multi;
            slaves.a.pcm "hw:0,2";
            slaves.a.channels 16;
            slaves.b.pcm ice1712_convert;
            slaves.b.channels 8;
            
            # Interleaved SBLive! and Delta1010LT inputs.
            #
            bindings.0.slave a;
            bindings.0.channel 10;
            bindings.1.slave b;
            bindings.1.channel 0;
            bindings.2.slave a;
            bindings.2.channel 11;
            bindings.3.slave b;
            bindings.3.channel 1;
            
            bindings.4.slave a;
            bindings.4.channel 12;
            bindings.5.slave b;
            bindings.5.channel 2;
            bindings.6.slave a;
            bindings.6.channel 13;
            bindings.7.slave b;
            bindings.7.channel 3;
            
            bindings.8.slave a;
            bindings.8.channel 14;
            bindings.9.slave b;
            bindings.9.channel 4;
            bindings.10.slave a;
            bindings.10.channel 15;
            bindings.11.slave b;
            bindings.11.channel 5;
          
            bindings.12.slave a;
            bindings.12.channel 0;
            bindings.13.slave b;
            bindings.13.channel 6;
            bindings.14.slave a;
            bindings.14.channel 1;
            bindings.15.slave b;
            bindings.15.channel 7;
          }

ctl.multi_rec {
            type hw;
            card 0;
          }



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

Re: Need help: My .asoundrc no longer works.

[John Rigg]

On Sat, Jan 20, 2007 at 12:39:20AM +0000, Tim wrote:
> Note the single use of a plug converter. This is the only way
>  I can make them work, converting the emu but not the ice gives 
>  'no playback configs avail', and converting both emu and ice gives
>  ALSA: could not complete read of 0 frames: error = -32
>  cycle execution failure, exiting
>  DRIVER NT: could not run driver cycle.
> 
> At first I though maybe a pcm multi problem. 
> I looked at changes to pcm_multi.c, not much change there, but I 'reverted'
>  a couple of things back to 1.0.9 state, but it didn't fix the problem.
> 
> Anyway, since the problem is always with the 'b' slave,
>  and since the 'b' slave always needs a converter, I'm wondering
>  if there's a problem with the 'plug' converter itself (or my plug sections).

You shouldn't need the plug converter if you specify the slaves channels
correctly. The ice1712 has 12 inputs and 10 outputs (regardless of how
many physical inputs/outputs your card has) and this needs to be
set explicitly in .asoundrc using separate playback and capture device
definitions. See here for explanation:

http://www.sound-man.co.uk/linuxaudio/ice1712multi.html

John

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

Re: Need help: My .asoundrc no longer works.

[Tim]

John Rigg <aldev <at> sound-man.co.uk> writes:

> You shouldn't need the plug converter if you specify the slaves channels
> correctly. The ice1712 has 12 inputs and 10 outputs (regardless of how
> many physical inputs/outputs your card has) and this needs to be
> set explicitly in .asoundrc using separate playback and capture device
> definitions. 
>
I should have been more clear. I am only using the multi device for record. 
My playback device is hw:1,0 - the ice1712, and I believe there is no 
 problem with it, because I can connect any jack input to those 
 outputs and get sound (except for the inputs I'm complaining about, of 
 course - the ones which come from 'b' slave - which can be the ice OR emu!). 
Inputs from other apps work. 
(And I should have said "ten hw:1,0" not "twelve hw:1,0" ouputs, sorry).


> See here for explanation:
> 
> http://www.sound-man.co.uk/linuxaudio/ice1712multi.html
>
I was going to contact your site:
       "type multi
        slaves.a.pcm hw:0      <--- No quotes? Jack won't start.
        slaves.a.channels 12
        slaves.b.pcm hw:1
        slaves.b.channels 12"
"You will also need this patch to prevent a floating point exception which   
 kills jackd at seemingly random times"
How does replacing a jack_nframes_t variable, (which is some sort of u32),
 with a double cure an fp exception? I'm running fine without it.

"Users may also have problems using the -rt kernel with pcm_multi. At the time  
 of writing, the -rt kernel (2.6.17-rt8) gives lots of xruns when using 
 pcm_multi (that's on AMD64 SMP - on UP it locks up completely). It works fine 
 with a single sound card."
Funny, me too! Seemed like once each display update of qjackctl, there
 would be a big burst of x-runs.
Until I realized I was still running the 'stock' jackit Mandriva2007 package,
 and I had not built my own jackit as I always do with the ramfs enabled. 
Well, ok, it was either THAT which cured my x-runs, or this patch mentioned:
"To make it work it's necessary to remove the linking code which was added in 
 pcm_multi.c rev 1.89. Here's a patch..." 
 which I tried but didn't cure my problems. It was the ramfs.
But I admit I'm running x86 not 64.

I notice that fp exception problem patch applies to a section called:
 /* post x-run handling */
Hmm, x-runs?...

Cheers. Tim.



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

Re: Need help: My .asoundrc no longer works.

[John Rigg]

On Sat, Jan 20, 2007 at 11:46:22AM -0500, Lee Revell wrote:
> On 1/20/07, John Rigg wrote:
> >You shouldn't need the plug converter if you specify the slaves channels
> >correctly. The ice1712 has 12 inputs and 10 outputs (regardless of how
> >many physical inputs/outputs your card has) and this needs to be
> >set explicitly in .asoundrc using separate playback and capture device
> >definitions. See here for explanation:
> 
> How could the above .asoundrc work given that the ICE1712 and EMU10K1
> devices are not synced at the hardware level?

Good question. I'm not familiar with the SBLive!, but I 
assumed (perhaps wrongly) that it had at least an S/PDIF output that
could be linked to the Delta's S/PDIF input.

jackd can actually run for a surprising length of time with unsynced
cards without alsa_pcm xrun messages (unlike jackdmp which produces a
slew of read errors), but I wouldn't expect to get a usable recording.

John

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

Re: Need help: My .asoundrc no longer works.

[Tim]

John Rigg <aldev <at> sound-man.co.uk> writes:

>> On Sat, Jan 20, 2007 at 11:46:22AM -0500, Lee Revell wrote:
  On 1/20/07, John Rigg wrote:
 You shouldn't need the plug converter if you specify the slaves channels
 correctly. The ice1712 has 12 inputs and 10 outputs (regardless of how
 many physical inputs/outputs your card has) and this needs to be
 set explicitly in .asoundrc using separate playback and capture device
 definitions. See here for explanation:
  
> How could the above .asoundrc work given that the ICE1712 and EMU10K1
 devices are not synced at the hardware level?

Hey! Did I miss something? Where is Lee Revell's message?

> Good question. I'm not familiar with the SBLive!, but I 
 assumed (perhaps wrongly) that it had at least an S/PDIF output that
 could be linked to the Delta's S/PDIF input.

Yep that's it. SPDIF from SBLive to Delta. They sync just fine.
Tim.


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

Re: Need help: My .asoundrc no longer works.

[Takashi Iwai]

At Sat, 20 Jan 2007 00:39:20 +0000 (UTC),
Tim wrote:
> 
> Thanks for the emu patch! Works ok now.
> 
> Now I have a problem I reeeeeally need help with.
> I have an SBLive! (emu10k1) as card 0 and an 
>  M-audio Delta1010LT (ice1712) as card 1.
> With alsa-1.0.9 the following .asoundrc files worked OK.
> 
> But now I've installed Mandriva2007 (alsa-1.0.12).

It's way too old to debug...  Please try the latest version,
1.0.14rc2, at first.


Takashi

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

Re: Need help: My .asoundrc no longer works.

[Tim]

Takashi Iwai <tiwai <at> suse.de> writes:
> It's way too old to debug...  Please try the latest version,
> 1.0.14rc2, at first.

I installed alsa 1.0.14rc2, but now the situation is worse.
Now multi refuses to work at all no matter what I try in
 .asoundrc
Remember: I have an emu10k1 based card, which can only
 use 8 or 16 bits, and an ice1712 based card, which can
 only use 32 bits. Therefore I need a plug converter on
 one or both of the slaves.

I did some tests, and it seems that multi does not like
 the plug converter. The plug converter by itself seems to 
 work OK. Examples:

If I just do a simple plug conversion on either card alone like this:
 arecord -c12 -r 48000 -f U8 -Dplughw:1,0 test.wav
or
 arecord -c8 -r 48000 -f U8 -Dplughw:0,2 test.wav
it works.

However if I do a simple multi with only ONE slave:

.asoundrc:
  pcm.ice1712 { type hw; card 1; }
  pcm_slave.sl3 { pcm ice1712 }
  pcm.ice1712_convert { type plug; slave sl3; }
  pcm.multi_rec {
                 type multi
                 slaves.a.pcm ice1712_convert
                 slaves.a.channels 12
                 bindings.0.slave a;
                 bindings.0.channel 0;
                 bindings.1.slave a;
                 bindings.1.channel 1;
                 etc. (twelve bindings...) 
                }
 then
arecord -c12 -r 48000 -f U8 -Dmulti_rec test.wav
 fails with:
ALSA lib pcm_mmap.c:141:(snd_pcm_mmap_read_areas) too short avail 0 to size 
1365
If I use the --avail-min option, then no matter how high a value I set,
 arecord just spews out x-runs forever, even with the -d option set at 1, for 
ex.

But if I do this:
arecord -c12 -r 48000 -f S32_LE -Dmulti_rec test.wav
 then it works.
I get similar results if I use the emu10k1 card instead of the ice1712,
 except that it only likes S16_LE or U8.
So it seems multi does not accept plug conversion of anything 
 other than the native format (S32_LE for ice1712, S16_LE or U8 for emu10k1).
So therefore when I combine BOTH cards into one multi, then multi
 really falls down. No combination of plug values, or the order of the
 two slaves, works.

Note that all of this worked OK under alsa-1.0.9, and as I mentioned before,
 APPEARS to work under alsa-1.0.12 - but does not actually record any sound
 from the multi second slave.
Under alsa-1.0.12 I saw that arecord told me alsa lib could not IOCTL LINK
 or UNLINK the two cards. But this seems to be gone now, under alsa-1.0.14rc2.

>From that, I can see that the alsa team is working hard on this, but I
 wonder if we are regressing - getting worse...
Hope this helps you.

---------------------------------
There is one more important issue:
What happened to all the input gain controls (IPGA) in the ice1712 driver?
With alsa-1.0.14rc2 they are gone! They don't show up in envy24control,
 or any other mixer I try which shows ALL alsa controls.
If this is an attempt to unify the IPGA and ADC controls, I agree. Carry on.
Anyone who has used the envy24control knows it is a bit strange.
If you operate the ADC controls, the IPGA controls are forced to zero,
 likewise if you operate the IPGA controls, the ADC controls are forced
 to max. Unification of the two controls would make a lot of sense.
But I could not seem to get them to work properly with this alsa-1.0.14rc2

Thanks. Any suggestions or feedback appreciated.
I will happily test anything you throw at me... 
Tim.




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

ice1712 IPGA and ADC controls

[Alan Horstmann]

In his mailing-
'Re: [Alsa-devel] Need help: My .asoundrc no longer works.'

On Friday 26 January 2007 01:28, Tim wrote:

> ---------------------------------
> There is one more important issue:
> What happened to all the input gain controls (IPGA) in the ice1712 driver?
> With alsa-1.0.14rc2 they are gone! They don't show up in envy24control,
>  or any other mixer I try which shows ALL alsa controls.
> If this is an attempt to unify the IPGA and ADC controls, I agree. Carry
> on. Anyone who has used the envy24control knows it is a bit strange.
> If you operate the ADC controls, the IPGA controls are forced to zero,
>  likewise if you operate the IPGA controls, the ADC controls are forced
>  to max. Unification of the two controls would make a lot of sense.
> But I could not seem to get them to work properly with this alsa-1.0.14rc2
>
> Tim.

I was intending to raise this matter myself.  In the changelog 1.0.12 to 
1.0.13 I noticed this:-

  + AK4XXX AD/DA converters
    - ak4xxx - Remove bogus IPGA controls

      Remove IPGA volume controls and merge the IPGA range to ADC volume
      controls.  These two volumes are not really independent but connected
      simply in different ranges 0-0x7f and 0x80-max.  It doesn't make sense
      to provide two controls.

      Since both 0x7f and 0x80 specify 0dB, a hack is needed for IPGA range
      to skip 0x80 (increment one) for such controls.

But I could not find the changeset on Hg and was intending to ask about it.

>From an analogue electronics POV this may not be a wise change.  Adding gain 
usually worsens singal-to-noise ratio and other signal parameters, and 
attenuation may mean avoidable gain elsewhere. So the best operating point in 
general is with no gain or attenuation at the converter.  Then the minimum of 
either would be used if necessary, in conjuction with controls on the source 
equipment.

Thus to achieve best performance I would think it is important to be aware of 
both these controls separately.  That is what the Terratec 'Windows' driver 
for my ice1712 sound card does.  If gain is needed, for example, it may be 
better to add it elsewhere than at the converter.  The 'strange' behaviour of 
the two controls in 1.0.12 is in fact entirely correct and neccessary when 
the underlying electronics is considered -it is vitally important to avoid 
gain and attenuation together even though the effect seems the same.

Remember that the ice1712 creates essentially a semi-pro sound system, so the 
users should be aware of technical and signal performance tradeoffs 
throughout their equipment (eg mixing desk, effects units), and be able to 
make intelligent decisions about the best settings of them all.  User 
friendliness should not override technical quality issues in this case.  It 
is not really a domestic piece of kit (eg delta 1010, ews88, dsp24).

Alan


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

Re: ice1712 IPGA and ADC controls

[Tim]

Alan Horstmann <gineera <at> aspect135.co.uk> writes:

> On Friday 26 January 2007 01:28, Tim wrote:
> > What happened to all the input gain controls (IPGA) in the ice1712 driver?
> 
> I was intending to raise this matter myself.  In the changelog 1.0.12 to 
> 1.0.13 I noticed this:-
> 
>   + AK4XXX AD/DA converters
>     - ak4xxx - Remove bogus IPGA controls
> 
>       Remove IPGA volume controls and merge the IPGA range to ADC volume
>       controls.  These two volumes are not really independent but connected
>       simply in different ranges 0-0x7f and 0x80-max.  It doesn't make sense
>       to provide two controls.
> 
>       Since both 0x7f and 0x80 specify 0dB, a hack is needed for IPGA range
>       to skip 0x80 (increment one) for such controls.
> 
> But I could not find the changeset on Hg and was intending to ask about it.
> 
> >From an analogue electronics POV this may not be a wise change.  Adding gain 
> usually worsens singal-to-noise ratio and other signal parameters, and 
> attenuation may mean avoidable gain elsewhere. So the best operating point in 
> general is with no gain or attenuation at the converter.  Then the minimum of 
> either would be used if necessary, in conjuction with controls on the source 
> equipment.
I was going to mention this but left it out:
Sure, I agree it is important to be aware that one control is for ADC 
 attenuation and the other for input gain, but we can achieve the same
 thing with one control as long as it is labelled properly.
With the control in the exact middle (or some defined 0 reference point), 
 we would have 0db of gain (or attenuation). From there the user can adjust 
 up or down as desired.
I think the problem is poor labelling. I mean how exactly are we
 supposed to figure out the amount of gain or attenuation when
 the controls simply display "0-127" and "0-30" (or whatever it was). 
(The Windows version is the same). It should be labelled in db. 
That would be much clearer to everyone - above 0db and you're 
 introducing gain, below 0db and you're attenuating.

> Thus to achieve best performance I would think it is important to be aware of 
> both these controls separately.  That is what the Terratec 'Windows' driver 
> for my ice1712 sound card does.  If gain is needed, for example, it may be 
> better to add it elsewhere than at the converter.  The 'strange' behaviour of 
> the two controls in 1.0.12 is in fact entirely correct and neccessary when 
> the underlying electronics is considered -it is vitally important to avoid 
> gain and attenuation together even though the effect seems the same.
Actually it wouldn't let you have "gain and attenuation together", since 
 operating the IPGA controls forced the ADC controls to max, and operating 
 the ADC controls forced the IPGA controls to zero. This is why I say it
 DOES make PERFECT sense to merge them. If they allowed independent 
 adjustment, then merging would NOT be a good idea.

> 
> Remember that the ice1712 creates essentially a semi-pro sound system, so the 
> users should be aware of technical and signal performance tradeoffs 
> throughout their equipment (eg mixing desk, effects units), and be able to 
> make intelligent decisions about the best settings of them all.  User 
> friendliness should not override technical quality issues in this case.  It 
> is not really a domestic piece of kit (eg delta 1010, ews88, dsp24).
Yeah, tell me about it. I used to plug my guitar straight into my
 rackmount effects unit. Then I bought the 1010LT so I could use my effects
 unit in a send-return arrangement. Which means I now plug the guitar into
 the 1010 (thru a very $$$ Jensen-xformer-based DI box!), then send to the 
 effects unit, then return back to the 1010.
But all those little buffer and amplifier and adjustment stages on the 1010
 mean more noise by the time the signal gets to the effects unit, where
 the overdrive/distortion reeeally amplifies the extra noise. It has been 
 tough getting all the levels correct, with an acceptable noise level, but
 I have found a "happy" medium, and I'm enjoying it.

Cheers. Tim.


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

Re: ice1712 IPGA and ADC controls

[John Rigg]

On Fri, Jan 26, 2007 at 11:26:55PM +0000, Alan Horstmann wrote:
> In his mailing-
> 'Re: [Alsa-devel] Need help: My .asoundrc no longer works.'
> 
> On Friday 26 January 2007 01:28, Tim wrote:
> 
> > ---------------------------------
> > There is one more important issue:
> > What happened to all the input gain controls (IPGA) in the ice1712 driver?
> > With alsa-1.0.14rc2 they are gone! They don't show up in envy24control,
> >  or any other mixer I try which shows ALL alsa controls.
> > If this is an attempt to unify the IPGA and ADC controls, I agree. Carry
> > on. Anyone who has used the envy24control knows it is a bit strange.
> > If you operate the ADC controls, the IPGA controls are forced to zero,
> >  likewise if you operate the IPGA controls, the ADC controls are forced
> >  to max. Unification of the two controls would make a lot of sense.
> > But I could not seem to get them to work properly with this alsa-1.0.14rc2
> >
> > Tim.
> 
> I was intending to raise this matter myself.  In the changelog 1.0.12 to 
> 1.0.13 I noticed this:-
> 
>   + AK4XXX AD/DA converters
>     - ak4xxx - Remove bogus IPGA controls
> 
>       Remove IPGA volume controls and merge the IPGA range to ADC volume
>       controls.  These two volumes are not really independent but connected
>       simply in different ranges 0-0x7f and 0x80-max.  It doesn't make sense
>       to provide two controls.
> 
>       Since both 0x7f and 0x80 specify 0dB, a hack is needed for IPGA range
>       to skip 0x80 (increment one) for such controls.
> 
> But I could not find the changeset on Hg and was intending to ask about it.
> 
> >From an analogue electronics POV this may not be a wise change.  Adding gain 
> usually worsens singal-to-noise ratio and other signal parameters, and 
> attenuation may mean avoidable gain elsewhere. So the best operating point in 
> general is with no gain or attenuation at the converter.  Then the minimum of 
> either would be used if necessary, in conjuction with controls on the source 
> equipment.

I agree. The correct place to set input levels is in the output stage
of the preceding equipment, eg. mic preamp or mixing desk output.
Users of this type of equipment can reasonably be expected to know
that.

> Thus to achieve best performance I would think it is important to be aware of 
> both these controls separately.  That is what the Terratec 'Windows' driver 
> for my ice1712 sound card does.  If gain is needed, for example, it may be 
> better to add it elsewhere than at the converter.  The 'strange' behaviour of 
> the two controls in 1.0.12 is in fact entirely correct and neccessary when 
> the underlying electronics is considered -it is vitally important to avoid 
> gain and attenuation together even though the effect seems the same.
> 
> Remember that the ice1712 creates essentially a semi-pro sound system, so the 
> users should be aware of technical and signal performance tradeoffs 
> throughout their equipment (eg mixing desk, effects units), and be able to 
> make intelligent decisions about the best settings of them all.  User 
> friendliness should not override technical quality issues in this case.  It 
> is not really a domestic piece of kit (eg delta 1010, ews88, dsp24).

Yes, absolutely. The last thing this kind of card needs is for the
input signal to be degraded by changing the gain of the ADC. 
The user really needs to have separate control over this.
Hardware mixing is a slightly different matter as it's usually only used
for zero-latency monitoring when recording overdubs (ie. the mixed signal
never gets recorded so a slight degradation doesn't matter).

John

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

Re: ice1712 IPGA and ADC controls

[Tim]

Tim wrote:
> > > What happened to all the input gain controls (IPGA) in the ice1712 
driver?
Alan wrote:
> >     - ak4xxx - Remove bogus IPGA controls

I just looked at the AK4524 datasheet. 
Well, the gain and attenuation are certainly two seperate 
 parts of the chip combined into one register. But ultimately 
 are two means to an end.
Table 12, the IPGA Code Table says it all, for me.
See that gain (db) column? 
THAT is what I want to see when I look at a slider! How 'bout you?
To merge a point made previously: If users of these cards are 
 more "technical" or "professional", then they will understand
 what they are doing, either because they know, or we simply tell 
 them with a helpful line about this matter in the readme.
Right?
BTW if any mixer out there is to do this correctly it could only
 be envy24control. I don't know if any standard alsa mixer could 
 know about the specific db steps on these chips.

My spider senses tell me the envy24control devels are working on this. 
Right guys?... Hello?...

Tim.
P.S. I said I had trouble with envy24control. Switched to newest one. All OK!




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

Re: ice1712 IPGA and ADC controls

[Alan Horstmann]

On Sunday 28 January 2007 20:54, Tim wrote:
> Tim wrote:
> > > > What happened to all the input gain controls (IPGA) in the ice1712
>
> driver?
>
> Alan wrote:
> > >     - ak4xxx - Remove bogus IPGA controls
>
> I just looked at the AK4524 datasheet.
> Well, the gain and attenuation are certainly two seperate
>  parts of the chip combined into one register. But ultimately
>  are two means to an end.
> Table 12, the IPGA Code Table says it all, for me.
> See that gain (db) column?
> THAT is what I want to see when I look at a slider! How 'bout you?

I want to see controls that reflect the actual hardware, where it will 
influence the performance.  If the user does not understand the concepts of 
dynamic range, signal-to-noise ratio, clipping, headroom, harmonic distortion 
and others, then they are unlikely to get good results out of the rest of 
their studio equipment.  Knowing about those issues underlines why pre-ADC 
gain is vastly different from post-ADC digital attenuation, and the two 
should not be mixed up just because they both vary the gain from the socket 
to the pcm stream.

> To merge a point made previously: If users of these cards are
>  more "technical" or "professional", then they will understand
>  what they are doing, either because they know, or we simply tell
>  them with a helpful line about this matter in the readme.
> Right?
> BTW if any mixer out there is to do this correctly it could only
>  be envy24control. I don't know if any standard alsa mixer could
>  know about the specific db steps on these chips.
>
> My spider senses tell me the envy24control devels are working on this.
> Right guys?... Hello?...
>
> Tim.

Also, lets not confuse the controls the alsa driver provides with how a GUI 
mixer such as envy24control presents those to a user.  It seems (Takashi 
please confirm) that this change is removing the separate controls from the 
AK4524 driver code, meaning that no alsa-driver using AK4524 can provide them 
separately.  With a single control the driver has no way to dictate labelling 
of '0dB' level (or any other useful notes) when used in a mixer.

It is another issue whether, with 2 controls in the driver, the GUI should 
combine them to a single GUI slider.  In this case I would still augue 
strongly for two controls, due to the importance of the distinction in the 
electronic circuit functions on the signal performance.


Alan


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

Re: ice1712 IPGA and ADC controls

[Fons Adriaensen]

On Mon, Jan 29, 2007 at 09:09:05AM +0000, Alan Horstmann wrote:

> Also, lets not confuse the controls the alsa driver provides with how a GUI 
> mixer such as envy24control presents those to a user.  It seems (Takashi 
> please confirm) that this change is removing the separate controls from the 
> AK4524 driver code, meaning that no alsa-driver using AK4524 can provide them 
> separately.  With a single control the driver has no way to dictate labelling 
> of '0dB' level (or any other useful notes) when used in a mixer.

I missed the start of this thread, but if the idea is to combine analog and
digital gain controls into one, that would be _a very bad idea_ and make a
card useless for any pro or semi-pro use. 

If users don't understand the difference, they should be informed. If they
still don't want to understand it, they should be encouraged to switch to
some other form of entertainment.


-- 
FA

Lascia la spina, cogli la rosa.


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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Mon, 29 Jan 2007 10:47:43 +0100,
Fons Adriaensen wrote:
> 
> On Mon, Jan 29, 2007 at 09:09:05AM +0000, Alan Horstmann wrote:
> 
> > Also, lets not confuse the controls the alsa driver provides with how a GUI 
> > mixer such as envy24control presents those to a user.  It seems (Takashi 
> > please confirm) that this change is removing the separate controls from the 
> > AK4524 driver code, meaning that no alsa-driver using AK4524 can provide them 
> > separately.  With a single control the driver has no way to dictate labelling 
> > of '0dB' level (or any other useful notes) when used in a mixer.
> 
> I missed the start of this thread, but if the idea is to combine analog and
> digital gain controls into one, that would be _a very bad idea_ and make a
> card useless for any pro or semi-pro use. 

Actually, the combination of attenuation and IPGA _is_ the very design
of this chip.  The driver is implemented as it is.

> If users don't understand the difference, they should be informed. If they
> still don't want to understand it, they should be encouraged to switch to
> some other form of entertainment.

That's a role of the mixer application - or a usability problem.  In
the earlier version, the driver gave two individual controls and this
messed up because they aren't individually controlled at all in
reality.


Takashi

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

Re: ice1712 IPGA and ADC controls

[Alan Horstmann]

On Saturday 27 January 2007 12:38, John Rigg wrote:
> On Fri, Jan 26, 2007 at 11:26:55PM +0000, Alan Horstmann wrote:
> > From an analogue electronics POV this may not be a wise change.  Adding
> > gain usually worsens singal-to-noise ratio and other signal parameters,
> > and attenuation may mean avoidable gain elsewhere. So the best operating
> > point in general is with no gain or attenuation at the converter.  Then
> > the minimum of either would be used if necessary, in conjuction with
> > controls on the source equipment.
>
> I agree. The correct place to set input levels is in the output stage
> of the preceding equipment, eg. mic preamp or mixing desk output.
> Users of this type of equipment can reasonably be expected to know
> that.
>
> > Thus to achieve best performance I would think it is important to be
> > aware of both these controls separately.  That is what the Terratec
> > 'Windows' driver for my ice1712 sound card does.  If gain is needed, for
> > example, it may be better to add it elsewhere than at the converter.  The
> > 'strange' behaviour of the two controls in 1.0.12 is in fact entirely
> > correct and neccessary when the underlying electronics is considered -it
> > is vitally important to avoid gain and attenuation together even though
> > the effect seems the same.
> >
> > Remember that the ice1712 creates essentially a semi-pro sound system, so
> > the users should be aware of technical and signal performance tradeoffs
> > throughout their equipment (eg mixing desk, effects units), and be able
> > to make intelligent decisions about the best settings of them all.  User
> > friendliness should not override technical quality issues in this case. 
> > It is not really a domestic piece of kit (eg delta 1010, ews88, dsp24).
>
> Yes, absolutely. The last thing this kind of card needs is for the
> input signal to be degraded by changing the gain of the ADC.
> The user really needs to have separate control over this.
> Hardware mixing is a slightly different matter as it's usually only used
> for zero-latency monitoring when recording overdubs (ie. the mixed signal
> never gets recorded so a slight degradation doesn't matter).
>
> John

(Adding to my previous posting)
What John and I are saying is that the driver should retain these two as 
separate controls as they perform distinct hardware functions, inspite of the 
similar nominal effect on gain.  There is no way for the driver to ensure 
that any user GUI labels the dual function of a combined control or will mark 
the '0dB' (no gain, no ADC attenuation) level of any fader/control.  In this 
case, the two controls need to be there to tell the user about the hardware, 
and the choices to be made about the settings, rather than hiding this.  Thus 
I advocate reverting to the 1.0.12 behaviour.

Having separate driver controls still permits a dedicated mixer app or similar 
to create a combined slider with suitable markings etc if that were 
appropriate to it's target user group, though as already said, these are 
mostly semi-pro system cards.


Alan


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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Sun, 28 Jan 2007 22:59:52 +0000,
Alan Horstmann wrote:
> 
> On Saturday 27 January 2007 12:38, John Rigg wrote:
> > On Fri, Jan 26, 2007 at 11:26:55PM +0000, Alan Horstmann wrote:
> > > From an analogue electronics POV this may not be a wise change.  Adding
> > > gain usually worsens singal-to-noise ratio and other signal parameters,
> > > and attenuation may mean avoidable gain elsewhere. So the best operating
> > > point in general is with no gain or attenuation at the converter.  Then
> > > the minimum of either would be used if necessary, in conjuction with
> > > controls on the source equipment.
> >
> > I agree. The correct place to set input levels is in the output stage
> > of the preceding equipment, eg. mic preamp or mixing desk output.
> > Users of this type of equipment can reasonably be expected to know
> > that.
> >
> > > Thus to achieve best performance I would think it is important to be
> > > aware of both these controls separately.  That is what the Terratec
> > > 'Windows' driver for my ice1712 sound card does.  If gain is needed, for
> > > example, it may be better to add it elsewhere than at the converter.  The
> > > 'strange' behaviour of the two controls in 1.0.12 is in fact entirely
> > > correct and neccessary when the underlying electronics is considered -it
> > > is vitally important to avoid gain and attenuation together even though
> > > the effect seems the same.
> > >
> > > Remember that the ice1712 creates essentially a semi-pro sound system, so
> > > the users should be aware of technical and signal performance tradeoffs
> > > throughout their equipment (eg mixing desk, effects units), and be able
> > > to make intelligent decisions about the best settings of them all.  User
> > > friendliness should not override technical quality issues in this case. 
> > > It is not really a domestic piece of kit (eg delta 1010, ews88, dsp24).
> >
> > Yes, absolutely. The last thing this kind of card needs is for the
> > input signal to be degraded by changing the gain of the ADC.
> > The user really needs to have separate control over this.
> > Hardware mixing is a slightly different matter as it's usually only used
> > for zero-latency monitoring when recording overdubs (ie. the mixed signal
> > never gets recorded so a slight degradation doesn't matter).
> >
> > John
> 
> (Adding to my previous posting)
> What John and I are saying is that the driver should retain these two as 
> separate controls as they perform distinct hardware functions, inspite of the 
> similar nominal effect on gain.  There is no way for the driver to ensure 
> that any user GUI labels the dual function of a combined control or will mark 
> the '0dB' (no gain, no ADC attenuation) level of any fader/control.  In this 
> case, the two controls need to be there to tell the user about the hardware, 
> and the choices to be made about the settings, rather than hiding this.  Thus 
> I advocate reverting to the 1.0.12 behaviour.
> 
> Having separate driver controls still permits a dedicated mixer app or similar 
> to create a combined slider with suitable markings etc if that were 
> appropriate to it's target user group, though as already said, these are 
> mostly semi-pro system cards.

Well, the ice1712 hardware is somehow strange.  On this chip, both the
analog attenuation and the IPGA are connected with each other, and can
_not_ be controlled separately.  That is, when you set analog
attenuation to non-zero, you cannot set IPGA at all.  Similarly, if
you set IPGA non-zero, analaog attenuation must be zero.  Hence,
recent implementation is the straightforward implementation from the
hardware perspective.

If you want to have really separate volume bars, we can implement it
on envy24control.  IOW, it's rater a usability issue, and putting such
a complicated linking of two controls in the driver simply messes.


Takashi

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

Re: ice1712 IPGA and ADC controls

[Alan Horstmann]

On Monday 29 January 2007 12:16, you wrote:
> At Sun, 28 Jan 2007 22:59:52 +0000,
>
> Alan Horstmann wrote:
> > On Saturday 27 January 2007 12:38, John Rigg wrote:
> > > On Fri, Jan 26, 2007 at 11:26:55PM +0000, Alan Horstmann wrote:
> > > > From an analogue electronics POV this may not be a wise change. 
> > > > Adding gain usually worsens singal-to-noise ratio and other signal
> > > > parameters, and attenuation may mean avoidable gain elsewhere. So the
> > > > best operating point in general is with no gain or attenuation at the
> > > > converter.  Then the minimum of either would be used if necessary, in
> > > > conjuction with controls on the source equipment.
> > >
> > > I agree. The correct place to set input levels is in the output stage
> > > of the preceding equipment, eg. mic preamp or mixing desk output.
> > > Users of this type of equipment can reasonably be expected to know
> > > that.
> > >
> > > > Thus to achieve best performance I would think it is important to be
> > > > aware of both these controls separately.  That is what the Terratec
> > > > 'Windows' driver for my ice1712 sound card does.  If gain is needed,
> > > > for example, it may be better to add it elsewhere than at the
> > > > converter.  The 'strange' behaviour of the two controls in 1.0.12 is
> > > > in fact entirely correct and neccessary when the underlying
> > > > electronics is considered -it is vitally important to avoid gain and
> > > > attenuation together even though the effect seems the same.
> > > >
> > > > Remember that the ice1712 creates essentially a semi-pro sound
> > > > system, so the users should be aware of technical and signal
> > > > performance tradeoffs throughout their equipment (eg mixing desk,
> > > > effects units), and be able to make intelligent decisions about the
> > > > best settings of them all.  User friendliness should not override
> > > > technical quality issues in this case. It is not really a domestic
> > > > piece of kit (eg delta 1010, ews88, dsp24).
> > >
> > > Yes, absolutely. The last thing this kind of card needs is for the
> > > input signal to be degraded by changing the gain of the ADC.
> > > The user really needs to have separate control over this.
> > > Hardware mixing is a slightly different matter as it's usually only
> > > used for zero-latency monitoring when recording overdubs (ie. the mixed
> > > signal never gets recorded so a slight degradation doesn't matter).
> > >
> > > John
> >
> > (Adding to my previous posting)
> > What John and I are saying is that the driver should retain these two as
> > separate controls as they perform distinct hardware functions, inspite of
> > the similar nominal effect on gain.  There is no way for the driver to
> > ensure that any user GUI labels the dual function of a combined control
> > or will mark the '0dB' (no gain, no ADC attenuation) level of any
> > fader/control.  In this case, the two controls need to be there to tell
> > the user about the hardware, and the choices to be made about the
> > settings, rather than hiding this.  Thus I advocate reverting to the
> > 1.0.12 behaviour.
> >
> > Having separate driver controls still permits a dedicated mixer app or
> > similar to create a combined slider with suitable markings etc if that
> > were appropriate to it's target user group, though as already said, these
> > are mostly semi-pro system cards.
>
> Well, the ice1712 hardware is somehow strange.  On this chip, both the
> analog attenuation and the IPGA are connected with each other, and can
> _not_ be controlled separately.  That is, when you set analog
> attenuation to non-zero, you cannot set IPGA at all.  Similarly, if
> you set IPGA non-zero, analaog attenuation must be zero.  Hence,
> recent implementation is the straightforward implementation from the
> hardware perspective.
>
> If you want to have really separate volume bars, we can implement it
> on envy24control.  IOW, it's rater a usability issue, and putting such
> a complicated linking of two controls in the driver simply messes.

The hardware is not actually strange to an electronics engineer (or when the 
reason is understood).  The AK4524 datasheet shows that there is an analogue 
gain block first, with a minimum setting of 0dB = x1; ie it can only provide 
boost.  This drives the convertor which is followed by a digital attenuator 
(DATT), ie it can only reduce the gain.  But using post-convertor attenuation 
worsens headroom, bit-depth etc.  The manufacturers know that to use gain and  
DATT is bad, so they make sure in the chip it is prevented.  Seeing as it is 
then only possible to have one or the other but not both, the values can 
conveniently share a register.  That does not mean they consider the two 
equivalent.

I can understand that without audio hardware experience it seems a reasonable 
improvement to merge them in favour of usability.  However, those of us who 
have involvement in pro-audio are saying please don't merge these controls 
even if it makes software easier or more straightforward.  The behaviour of 
1.0.12 and previous was exactly right in helping the user be aware of 
important hardware issues (partly through the cross-coupling effect), right 
at the driver level so that it applies to any mixer used.

On these cards, the zero-gain/zero-DATT setting would be the one to use all 
the time unless unavoidable.  It needs to be not simply somewhere in the 
middle of a control range.

BTW did the change actually make it into 1.0.13?


Alan


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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Mon, 29 Jan 2007 17:07:34 +0000,
Alan Horstmann wrote:
> 
> On Monday 29 January 2007 12:16, you wrote:
> > At Sun, 28 Jan 2007 22:59:52 +0000,
> >
> > Alan Horstmann wrote:
> > > On Saturday 27 January 2007 12:38, John Rigg wrote:
> > > > On Fri, Jan 26, 2007 at 11:26:55PM +0000, Alan Horstmann wrote:
> > > > > From an analogue electronics POV this may not be a wise change. 
> > > > > Adding gain usually worsens singal-to-noise ratio and other signal
> > > > > parameters, and attenuation may mean avoidable gain elsewhere. So the
> > > > > best operating point in general is with no gain or attenuation at the
> > > > > converter.  Then the minimum of either would be used if necessary, in
> > > > > conjuction with controls on the source equipment.
> > > >
> > > > I agree. The correct place to set input levels is in the output stage
> > > > of the preceding equipment, eg. mic preamp or mixing desk output.
> > > > Users of this type of equipment can reasonably be expected to know
> > > > that.
> > > >
> > > > > Thus to achieve best performance I would think it is important to be
> > > > > aware of both these controls separately.  That is what the Terratec
> > > > > 'Windows' driver for my ice1712 sound card does.  If gain is needed,
> > > > > for example, it may be better to add it elsewhere than at the
> > > > > converter.  The 'strange' behaviour of the two controls in 1.0.12 is
> > > > > in fact entirely correct and neccessary when the underlying
> > > > > electronics is considered -it is vitally important to avoid gain and
> > > > > attenuation together even though the effect seems the same.
> > > > >
> > > > > Remember that the ice1712 creates essentially a semi-pro sound
> > > > > system, so the users should be aware of technical and signal
> > > > > performance tradeoffs throughout their equipment (eg mixing desk,
> > > > > effects units), and be able to make intelligent decisions about the
> > > > > best settings of them all.  User friendliness should not override
> > > > > technical quality issues in this case. It is not really a domestic
> > > > > piece of kit (eg delta 1010, ews88, dsp24).
> > > >
> > > > Yes, absolutely. The last thing this kind of card needs is for the
> > > > input signal to be degraded by changing the gain of the ADC.
> > > > The user really needs to have separate control over this.
> > > > Hardware mixing is a slightly different matter as it's usually only
> > > > used for zero-latency monitoring when recording overdubs (ie. the mixed
> > > > signal never gets recorded so a slight degradation doesn't matter).
> > > >
> > > > John
> > >
> > > (Adding to my previous posting)
> > > What John and I are saying is that the driver should retain these two as
> > > separate controls as they perform distinct hardware functions, inspite of
> > > the similar nominal effect on gain.  There is no way for the driver to
> > > ensure that any user GUI labels the dual function of a combined control
> > > or will mark the '0dB' (no gain, no ADC attenuation) level of any
> > > fader/control.  In this case, the two controls need to be there to tell
> > > the user about the hardware, and the choices to be made about the
> > > settings, rather than hiding this.  Thus I advocate reverting to the
> > > 1.0.12 behaviour.
> > >
> > > Having separate driver controls still permits a dedicated mixer app or
> > > similar to create a combined slider with suitable markings etc if that
> > > were appropriate to it's target user group, though as already said, these
> > > are mostly semi-pro system cards.
> >
> > Well, the ice1712 hardware is somehow strange.  On this chip, both the
> > analog attenuation and the IPGA are connected with each other, and can
> > _not_ be controlled separately.  That is, when you set analog
> > attenuation to non-zero, you cannot set IPGA at all.  Similarly, if
> > you set IPGA non-zero, analaog attenuation must be zero.  Hence,
> > recent implementation is the straightforward implementation from the
> > hardware perspective.
> >
> > If you want to have really separate volume bars, we can implement it
> > on envy24control.  IOW, it's rater a usability issue, and putting such
> > a complicated linking of two controls in the driver simply messes.
> 
> The hardware is not actually strange to an electronics engineer (or when the 
> reason is understood).  The AK4524 datasheet shows that there is an analogue 
> gain block first, with a minimum setting of 0dB = x1; ie it can only provide 
> boost.  This drives the convertor which is followed by a digital attenuator 
> (DATT), ie it can only reduce the gain.  But using post-convertor attenuation 
> worsens headroom, bit-depth etc.  The manufacturers know that to use gain and  
> DATT is bad, so they make sure in the chip it is prevented.  Seeing as it is 
> then only possible to have one or the other but not both, the values can 
> conveniently share a register.  That does not mean they consider the two 
> equivalent.
> 
> I can understand that without audio hardware experience it seems a reasonable 
> improvement to merge them in favour of usability.  However, those of us who 
> have involvement in pro-audio are saying please don't merge these controls 
> even if it makes software easier or more straightforward.  The behaviour of 
> 1.0.12 and previous was exactly right in helping the user be aware of 
> important hardware issues (partly through the cross-coupling effect), right 
> at the driver level so that it applies to any mixer used.

The behavior of these controls were not right at all because the
linkage between IPGA and analog controls were not handled in the
driver.  It worked just only with envy24control simply because it has
a special hack.

So, the same is true - we just need a special hack in envy24control
but in more cleaner way than before.  OK?


Takashi

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

Re: ice1712 IPGA and ADC controls

[John Rigg]

On Mon, Jan 29, 2007 at 01:16:05PM +0100, Takashi Iwai wrote:
> At Sun, 28 Jan 2007 22:59:52 +0000,
> Well, the ice1712 hardware is somehow strange.  On this chip, both the
> analog attenuation and the IPGA are connected with each other, and can
> _not_ be controlled separately.  That is, when you set analog
> attenuation to non-zero, you cannot set IPGA at all.  Similarly, if
> you set IPGA non-zero, analaog attenuation must be zero.  Hence,
> recent implementation is the straightforward implementation from the
> hardware perspective.

If a single volume bar is implemented, does it leave the analog
attenuation at zero and adjust the digital attenuation, or does
it leave the digital attenuation at zero and adjust the analog
attenuation? If I had to choose one or the other it would usually
be the latter. Digital and analog attenuation are not the same in
terms of quality, especially when the digital attenuation acts on
integer samples as opposed to floating point.

I can see the argument for making it simple for the non-technical
user, but the quality level required by the pro/semi-pro user must
still be attainable. Personally I'd rather see both sets of controls
in the driver, even if only one volume bar appears in the mixer app.
At least then there's still the option of controlling one or the other
(even if it means patching envy24control ;-)).

John

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

Re: ice1712 IPGA and ADC controls

[Tim]

John Rigg <aldev <at> sound-man.co.uk> writes:

> If a single volume bar is implemented, does it leave the analog
> attenuation at zero and adjust the digital attenuation, or does
> it leave the digital attenuation at zero and adjust the analog
> attenuation? 
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.
It was intended to be one control.

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.
 


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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Tue, 30 Jan 2007 06:18:38 +0000 (UTC),
Tim wrote:
> 
> John Rigg <aldev <at> sound-man.co.uk> writes:
> 
> > If a single volume bar is implemented, does it leave the analog
> > attenuation at zero and adjust the digital attenuation, or does
> > it leave the digital attenuation at zero and adjust the analog
> > attenuation? 
> 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.
> It was intended to be one control.

Exactly.  Thanks for correction.

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

Comments?  Other suggestsion?


Takashi

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

Re: ice1712 IPGA and ADC controls

[Tim]

Takashi Iwai <tiwai <at> suse.de> writes:
> 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.
The answer is obvious - combine them into one control! He he...



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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Tue, 30 Jan 2007 23:01:45 +0000 (UTC),
Tim wrote:
> 
> Takashi Iwai <tiwai <at> suse.de> writes:
> > 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.
> The answer is obvious - combine them into one control! He he...

Yeah!  That would be easiest :^)


Takashi

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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Wed, 31 Jan 2007 09:48:17 +0100,
I wrote:
> 
> At Tue, 30 Jan 2007 23:01:45 +0000 (UTC),
> Tim wrote:
> > 
> > Takashi Iwai <tiwai <at> suse.de> writes:
> > > 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.
> > The answer is obvious - combine them into one control! He he...
> 
> Yeah!  That would be easiest :^)

After reading your post again, I found myself maybe misunderstanding.

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

Did you mean something that looks like below?

    +---+ +18dB
    |   |
    |   | analog
    |   | gain
    |   |
    +---+ 0dB
    |   |
    |   | digital
    |   | att 
    |[=]--[ -30dB ]
    |   |
    +---+ -64dB


Takashi

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

Re: ice1712 IPGA and ADC controls

[Fons Adriaensen]

On Wed, Jan 31, 2007 at 11:33:30AM +0100, Takashi Iwai wrote:
> 
>     +---+ +18dB
>     |   |
>     |   | analog
>     |   | gain
>     |   |
>     +---+ 0dB
>     |   |
>     |   | digital
>     |   | att 
>     |[=]--[ -30dB ]
>     |   |
>     +---+ -64dB

This seems a good solution. BTW, is this issue somehow related to
the bug I experienced first with SuSE 8.1 and which is AFAIK still
there in 10.0, resulting in the gain controls in envy24control with
the Terratec EWS88MT not working properly ? 

-- 
FA

Lascia la spina, cogli la rosa.


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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

At Wed, 31 Jan 2007 22:48:58 +0100,
Fons Adriaensen wrote:
> 
> On Wed, Jan 31, 2007 at 11:33:30AM +0100, Takashi Iwai wrote:
> > 
> >     +---+ +18dB
> >     |   |
> >     |   | analog
> >     |   | gain
> >     |   |
> >     +---+ 0dB
> >     |   |
> >     |   | digital
> >     |   | att 
> >     |[=]--[ -30dB ]
> >     |   |
> >     +---+ -64dB
> 
> This seems a good solution. BTW, is this issue somehow related to
> the bug I experienced first with SuSE 8.1 and which is AFAIK still
> there in 10.0, resulting in the gain controls in envy24control with
> the Terratec EWS88MT not working properly ? 

Oh what a legacy OS :)

I guess it's a different problem, likely somewhat wrong in the
communcation between ice1712 and ak codecs.  Unfortunately, I couldn't
reproduce your problem on my test environment...


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

Re: ice1712 IPGA and ADC controls

[Tim]

Takashi Iwai <tiwai <at> suse.de> writes (er... draws): 
 
>     +---+ +18dB 
>     |   | 
>     |   | analog 
>     |   | gain 
>     |   | 
>     +---+ 0dB 
>     |   | 
>     |   | digital 
>     |   | att  
>     |[=]--[ -30dB ] 
>     |   | 
>     +---+ -64dB 
>  
 
My, what lovely ascii art. But who will port envy24control to ncurses?  
Yeah, that's it, kinda.  
 
Also my Delta1010's Windows driver mixer-app has  
 db numbers on the monitor mixer tab's vu meters. 
 
Curiously, a quote from my manual about the Windows mixer-app: 
 
 "The (dac/adc) faders can be set incrementally in 0.5db steps, 
  of which there are 18." 
 
I'm scratching my head - what the heck do they mean by 18 0.5db steps?  
That's not nearly enough to cover the range! 
And looking at IPGA gain table of the chip, I wonder how they would  
 accomplish that. The specific db steps of each level are very unusual  
 and follow a pseudo-log scheme, and in many places an exact 0.5db 
 step doesn't look possible. 
 


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

Re: ice1712 IPGA and ADC controls

[Alan Horstmann]

On Thursday 01 February 2007 05:01, Tim wrote:
>
> Also my Delta1010's Windows driver mixer-app has
>  db numbers on the monitor mixer tab's vu meters.

How do M-Audio display the IPGA and DATT controls in this Windows driver?  Are 
they combined?  Terratec use a rotary IPGA control above the fader.


> Curiously, a quote from my manual about the Windows mixer-app:
>
>  "The (dac/adc) faders can be set incrementally in 0.5db steps,
>   of which there are 18."
>
> I'm scratching my head - what the heck do they mean by 18 0.5db steps?
> That's not nearly enough to cover the range!

A manual error I think due to trying to shorten sentences.  There are 18 dB of 
adjustment, in steps of 0.5dB is probably what was meant to be said!


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

Re: ice1712 IPGA and ADC controls

[Alan Horstmann]

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

Re: ice1712 IPGA and ADC controls

[Takashi Iwai]

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

Re: ice1712 IPGA and ADC controls

[John Rigg]

On Tue, Jan 30, 2007 at 06:18:38AM +0000, 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.
> It was intended to be one control.

That makes sense (thanks for the clarification). I think it's
important to clearly mark the 0dB point, and also to make 0dB
the default setting.

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

Good idea.

> And of course all values in db's as well as integers.

dB would be nice.

John

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

Re: Need help: My .asoundrc no longer works.

[Tim]

Tim <terminator356 <at> users.sourceforge.net> writes:
> 
> Takashi Iwai <tiwai <at> suse.de> writes:
> > It's way too old to debug...  Please try the latest version,
> > 1.0.14rc2, at first.
> 
> I installed alsa 1.0.14rc2, but now the situation is worse.
> Now multi refuses to work at all no matter what I try in
>  .asoundrc

Sorry, it turns out that in fact I am getting the same
 results as under alsa-1.0.12.
My multi DOES work, but refuses to record any sound from the
 second slave, no matter whether I make the second slave emu10k1 or 
 the ice1712.
Even with LIBASOUND_DEBUG=1, there is no indication of any trouble
 during arecord. arecord will happily record all channels in the
 multi - but examination of the resulting raw files shows complete
 silence is recorded from ALL of the second slave's channels.
Alsa is 'quietly' having trouble somewhere, without reporting any error. 

I am currently deep into the alsa-driver code, inserting printk
 'checkpoints' to try and find out what's happening.

So, while I do that, is any one else having these troubles?
Any ideas, Takashi?
Thanks. Tim.



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