GPIO connections for the M-Audio Revolution 5.1

GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

Hello,

last week I reported bug #2325: capturing sound on the M-Audio
Revolution 5.1 does not work.  While trying to figure out the
cause of the problem, I encountered the following question:

What are the GPIO pins of the Envy24GT connected to for this card?
Since there is already a driver, somebody will probably have figured
this out, but I could not find documented anywhere.

What I did find out:

1) The ice1712/revo.h header file (shared by Revolution 7.1 and 5.1)
defines the following:

#define VT1724_REVO_CCLK	0x02
#define VT1724_REVO_CDIN	0x04	/* not used */
#define VT1724_REVO_CDOUT	0x08
#define VT1724_REVO_CS0		0x10	/* not used */
#define VT1724_REVO_CS1		0x20	/* front AKM4381 chipselect */
#define VT1724_REVO_CS2		0x40	/* surround AKM4355 chipselect */
#define VT1724_REVO_MUTE	(1<<22)	/* 0 = all mute, 1 = normal operation */

Why are the "not used" ones there?

2) From visual inspection of the card (a photo is at
http://seehuhn.de/comp/hardware/revoboard.jpg ) I think that the
following GPIO pins are connected to something:

    0x01 (seems to go to the PCI bus)
    0x02
    0x04
    0x20
    0x40
    0x80
    (1<<22)

Note that 0x80 is not mentioned in the header file.  Is this a
problem?

3) I think that AK4381 and AK4355 as mentioned in the header file are
DACs.  The Revolution 5.1 has only one DAC (an AK4358), not two.
Could this cause problems?

Many thanks,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Mon, 7 Aug 2006 21:31:14 +0100,
Jochen Voss wrote:
> 
> Hello,
> 
> last week I reported bug #2325: capturing sound on the M-Audio
> Revolution 5.1 does not work.  While trying to figure out the
> cause of the problem, I encountered the following question:
> 
> What are the GPIO pins of the Envy24GT connected to for this card?
> Since there is already a driver, somebody will probably have figured
> this out, but I could not find documented anywhere.

The document for 7.1 was not publicly released.  And no known document
for 5.1.  You should ask M-Audio about it.

> What I did find out:
> 
> 1) The ice1712/revo.h header file (shared by Revolution 7.1 and 5.1)
> defines the following:
> 
> #define VT1724_REVO_CCLK	0x02
> #define VT1724_REVO_CDIN	0x04	/* not used */
> #define VT1724_REVO_CDOUT	0x08
> #define VT1724_REVO_CS0		0x10	/* not used */
> #define VT1724_REVO_CS1		0x20	/* front AKM4381 chipselect */
> #define VT1724_REVO_CS2		0x40	/* surround AKM4355 chipselect */
> #define VT1724_REVO_MUTE	(1<<22)	/* 0 = all mute, 1 = normal operation */
> 
> Why are the "not used" ones there?

Why not? :)

> 2) From visual inspection of the card (a photo is at
> http://seehuhn.de/comp/hardware/revoboard.jpg ) I think that the
> following GPIO pins are connected to something:
> 
>     0x01 (seems to go to the PCI bus)
>     0x02
>     0x04
>     0x20
>     0x40
>     0x80
>     (1<<22)
> 
> Note that 0x80 is not mentioned in the header file.  Is this a
> problem?

Might be.  The code was originally written for Revo 7.1, and I have no
revo 5.1.  Just heard that it works so.

> 3) I think that AK4381 and AK4355 as mentioned in the header file are
> DACs.  The Revolution 5.1 has only one DAC (an AK4358), not two.
> Could this cause problems?

Not probablly but possible although the capture is likely dependent
only on the ADC connection.

Actually, it's a shot in the dark.  No-one can answer this kind of
question correctly except for M-Audio guys...


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 1331 bytes --]

Hello Takashi,

On Tue, Aug 08, 2006 at 12:21:37PM +0200, Takashi Iwai wrote:
> The document for 7.1 was not publicly released.  And no known document
> for 5.1.  You should ask M-Audio about it.

I will be away for a few days so now is a bad time.
But I will try to ask them once I am back.
Is there a know contact person, or is the plan
to just search through their web page for a feasible
communication channel and then use this?

> > 1) The ice1712/revo.h header file (shared by Revolution 7.1 and 5.1)
> > defines the following:
> > 
> > #define VT1724_REVO_CCLK	0x02
> > #define VT1724_REVO_CDIN	0x04	/* not used */
> > #define VT1724_REVO_CDOUT	0x08
> > #define VT1724_REVO_CS0		0x10	/* not used */
> > #define VT1724_REVO_CS1		0x20	/* front AKM4381 chipselect */
> > #define VT1724_REVO_CS2		0x40	/* surround AKM4355 chipselect */
> > #define VT1724_REVO_MUTE	(1<<22)	/* 0 = all mute, 1 = normal operation */
> > 
> > Why are the "not used" ones there?
> 
> Why not? :)

Because they are not used?

> > Note that 0x80 is not mentioned in the header file.  Is this a
> > problem?
> 
> Might be.  The code was originally written for Revo 7.1, and I have no
> revo 5.1.  Just heard that it works so.

Playback works fine.  Capture does not.

Many thanks,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 11:40:15 +0100,
Jochen Voss wrote:
> 
> Hello Takashi,
> 
> On Tue, Aug 08, 2006 at 12:21:37PM +0200, Takashi Iwai wrote:
> > The document for 7.1 was not publicly released.  And no known document
> > for 5.1.  You should ask M-Audio about it.
> 
> I will be away for a few days so now is a bad time.
> But I will try to ask them once I am back.
> Is there a know contact person, or is the plan
> to just search through their web page for a feasible
> communication channel and then use this?
> 
> > > 1) The ice1712/revo.h header file (shared by Revolution 7.1 and 5.1)
> > > defines the following:
> > > 
> > > #define VT1724_REVO_CCLK	0x02
> > > #define VT1724_REVO_CDIN	0x04	/* not used */
> > > #define VT1724_REVO_CDOUT	0x08
> > > #define VT1724_REVO_CS0		0x10	/* not used */
> > > #define VT1724_REVO_CS1		0x20	/* front AKM4381 chipselect */
> > > #define VT1724_REVO_CS2		0x40	/* surround AKM4355 chipselect */
> > > #define VT1724_REVO_MUTE	(1<<22)	/* 0 = all mute, 1 = normal operation */
> > > 
> > > Why are the "not used" ones there?
> > 
> > Why not? :)
> 
> Because they are not used?

But information is always good.  Actually, M-Audio mentioned that they
might use these for a future model.

> > > Note that 0x80 is not mentioned in the header file.  Is this a
> > > problem?
> > 
> > Might be.  The code was originally written for Revo 7.1, and I have no
> > revo 5.1.  Just heard that it works so.
> 
> Playback works fine.  Capture does not.

Note that revo 7.1 has no volume control for the capture at all
since its ADC chip (AK5380) has really no control.

What ADC chip is on revo 5.1?


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 706 bytes --]

Hello Takashi,

On Tue, Aug 08, 2006 at 01:07:42PM +0200, Takashi Iwai wrote:
> > > > Why are the "not used" ones there?
> > > 
> > > Why not? :)
> > 
> > Because they are not used?
> 
> But information is always good.  Actually, M-Audio mentioned that they
> might use these for a future model.

Oh, ok, then they should of course stay.

> Note that revo 7.1 has no volume control for the capture at all
> since its ADC chip (AK5380) has really no control.
> 
> What ADC chip is on revo 5.1?

AK5365, according to the spec (page 21) this one has volume control.
Maybe recording is just a matter of putting the volume up on this
chip?

Many thanks,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 12:18:50 +0100,
Jochen Voss wrote:
> 
> > Note that revo 7.1 has no volume control for the capture at all
> > since its ADC chip (AK5380) has really no control.
> > 
> > What ADC chip is on revo 5.1?
> 
> AK5365, according to the spec (page 21) this one has volume control.
> Maybe recording is just a matter of putting the volume up on this
> chip?

Ah, then 0x80 makes sense.  It's possibly a chip-select for that ADC
chip.


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 662 bytes --]

Hi Takashi,

On Tue, Aug 08, 2006 at 01:23:27PM +0200, Takashi Iwai wrote:
> > AK5365, according to the spec (page 21) this one has volume control.
> > Maybe recording is just a matter of putting the volume up on this
> > chip?
> 
> Ah, then 0x80 makes sense.  It's possibly a chip-select for that ADC
> chip.

I took out the card and had another look.  I don't have any measuring
equipment, so I am limited to staring at the board.  It might be, that
GPIO pin 0x80 is connected to pin 33 (CSN/CAD1) of the AK5365.  Would
this make sense?

Do you know whether the card uses 3-wire control or I2C?

Many thanks,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 12:40:33 +0100,
Jochen Voss wrote:
> 
> Hi Takashi,
> 
> On Tue, Aug 08, 2006 at 01:23:27PM +0200, Takashi Iwai wrote:
> > > AK5365, according to the spec (page 21) this one has volume control.
> > > Maybe recording is just a matter of putting the volume up on this
> > > chip?
> > 
> > Ah, then 0x80 makes sense.  It's possibly a chip-select for that ADC
> > chip.
> 
> I took out the card and had another look.  I don't have any measuring
> equipment, so I am limited to staring at the board.  It might be, that
> GPIO pin 0x80 is connected to pin 33 (CSN/CAD1) of the AK5365.  Would
> this make sense?

Yes.

> Do you know whether the card uses 3-wire control or I2C?

My rough guess is 3-wire control, using the same CLK (0x02) and CIN
(0x04) with a different CS (0x80).  Or possibly CS0 (0x10) or CS2
(0x40) is used instead.  Currently the driver resets all CS0-2 bits
for a single AK4358 chip, but only one of them should be needed.


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 2689 bytes --]

Hi Takashi,

On Tue, Aug 08, 2006 at 03:07:10PM +0200, Takashi Iwai wrote:
> My rough guess is 3-wire control, using the same CLK (0x02) and CIN
> (0x04) with a different CS (0x80).  Or possibly CS0 (0x10) or CS2
> (0x40) is used instead.  Currently the driver resets all CS0-2 bits
> for a single AK4358 chip, but only one of them should be needed.

I might have been confused when I wrote about GPIO pins before.

1) I claimed that GPIO0 is connected to the PCI bus.
This was wrong, I confused it with the address line next to it.
I apologise for the confusion.

2) From visual inspection I would think that only GPIO0, GPIO2, GPIO5,
GPIO6, GPIO7 and GPIO22 are connected.  The others are connected to
dark areas which I take to be the ground.  But this might be wrong,
too, since ...

3) I played around with the code in alsa-kernel/pci/ice1724/revo.c and
more specifically with the akm_revo51_priv structure there.  Originally
it is initialised as

static struct snd_ak4xxx_private akm_revo51_priv __devinitdata = {
	.caddr = 2,
	.cif = 0,
	.data_mask = VT1724_REVO_CDOUT,
	.clk_mask = VT1724_REVO_CCLK,
	.cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS1 | VT1724_REVO_CS2,
	.cs_addr = 0,
	.cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS1 | VT1724_REVO_CS2,
	.add_flags = VT1724_REVO_CCLK, /* high at init */
	.mask_flags = 0,
};

I tried several combinations of CS0, CS1 and CS2 in the .cs_addr field.
Results:

    .cs_addr  | result
 ------------------------------------------------------
       0      | playback: ok, capture: no
      CS1     | playback: ok, capture: works!
      CS2     | playback: ok, capture: no
      CS1|CS2 | playback: ok, capture: works!
      CS0     | playback: very noisy, capture: no
      CS0|CS1 | playback: very noisy, capture: works!

where

    "capture: works!" means, that arecord no longer returns 0 bytes.
    I did not yet try to record something meaningful, but without a
    microphone connected I get something which looks like line noise
    to me.

    "playback: very noisy": the signal is overlayed by a lot of noise.
    The volume control elements of the mixer no longer work.  The
    "H/W" element switches off the music (but not the noise) for the
    right speaker when not set to "PCM out".  Similarly the "H/W 1"
    element switches off the music (but not the noise) for the left
    speaker when not set to "PCM out".

Conclusions:

(1) GPIO4 seems to be connected (I still can't see this on the board),
otherwise the CS0 setting would not have any effect.

(2) Setting CS1 seems to enable the capture channel.

I hope this helps,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 17:30:25 +0100,
Jochen Voss wrote:
> 
> Hi Takashi,
> 
> On Tue, Aug 08, 2006 at 03:07:10PM +0200, Takashi Iwai wrote:
> > My rough guess is 3-wire control, using the same CLK (0x02) and CIN
> > (0x04) with a different CS (0x80).  Or possibly CS0 (0x10) or CS2
> > (0x40) is used instead.  Currently the driver resets all CS0-2 bits
> > for a single AK4358 chip, but only one of them should be needed.
> 
> I might have been confused when I wrote about GPIO pins before.
> 
> 1) I claimed that GPIO0 is connected to the PCI bus.
> This was wrong, I confused it with the address line next to it.
> I apologise for the confusion.
> 
> 2) From visual inspection I would think that only GPIO0, GPIO2, GPIO5,
> GPIO6, GPIO7 and GPIO22 are connected.  The others are connected to
> dark areas which I take to be the ground.  But this might be wrong,
> too, since ...
> 
> 3) I played around with the code in alsa-kernel/pci/ice1724/revo.c and
> more specifically with the akm_revo51_priv structure there.  Originally
> it is initialised as
> 
> static struct snd_ak4xxx_private akm_revo51_priv __devinitdata = {
> 	.caddr = 2,
> 	.cif = 0,
> 	.data_mask = VT1724_REVO_CDOUT,
> 	.clk_mask = VT1724_REVO_CCLK,
> 	.cs_mask = VT1724_REVO_CS0 | VT1724_REVO_CS1 | VT1724_REVO_CS2,
> 	.cs_addr = 0,
> 	.cs_none = VT1724_REVO_CS0 | VT1724_REVO_CS1 | VT1724_REVO_CS2,
> 	.add_flags = VT1724_REVO_CCLK, /* high at init */
> 	.mask_flags = 0,
> };
> 
> I tried several combinations of CS0, CS1 and CS2 in the .cs_addr field.
> Results:
> 
>     .cs_addr  | result
>  ------------------------------------------------------
>        0      | playback: ok, capture: no
>       CS1     | playback: ok, capture: works!
>       CS2     | playback: ok, capture: no
>       CS1|CS2 | playback: ok, capture: works!
>       CS0     | playback: very noisy, capture: no
>       CS0|CS1 | playback: very noisy, capture: works!
> 
> where
> 
>     "capture: works!" means, that arecord no longer returns 0 bytes.
>     I did not yet try to record something meaningful, but without a
>     microphone connected I get something which looks like line noise
>     to me.
> 
>     "playback: very noisy": the signal is overlayed by a lot of noise.
>     The volume control elements of the mixer no longer work.  The
>     "H/W" element switches off the music (but not the noise) for the
>     right speaker when not set to "PCM out".  Similarly the "H/W 1"
>     element switches off the music (but not the noise) for the left
>     speaker when not set to "PCM out".
> 
> Conclusions:
> 
> (1) GPIO4 seems to be connected (I still can't see this on the board),
> otherwise the CS0 setting would not have any effect.
> 
> (2) Setting CS1 seems to enable the capture channel.

OK, this implies that CS0 is for DAC and CS1 for ADC.  CS2 isn't used,
so basically it doesn't matter to be set or not.

What we need next is to write up a code to communicate with ADC chip.
It could be merged into i2c/other/ak4xxx-adda.c, but it could be a
standlone implementation as found in aureon.c.


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 574 bytes --]

Hi Takashi,

On Tue, Aug 08, 2006 at 06:48:31PM +0200, Takashi Iwai wrote:
> OK, this implies that CS0 is for DAC and CS1 for ADC.  CS2 isn't used,
> so basically it doesn't matter to be set or not.
I agree.

> What we need next is to write up a code to communicate with ADC chip.
> It could be merged into i2c/other/ak4xxx-adda.c, but it could be a
> standlone implementation as found in aureon.c.
Yes, I am currently looking at ak4xxx-adda.c.
I will see what I can do and report the result later.

Many thanks for your help,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 441 bytes --]

Hi Takashi,

On Tue, Aug 08, 2006 at 06:48:31PM +0200, Takashi Iwai wrote:
> What we need next is to write up a code to communicate with ADC chip.
> It could be merged into i2c/other/ak4xxx-adda.c, but it could be a
> standlone implementation as found in aureon.c.

Is the last argument (mask) for AK_COMPOSE the maximum allowed mixer
value?  Is it ok if this is not a power of two?

Many thanks,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 18:20:37 +0100,
Jochen Voss wrote:
> 
> Hi Takashi,
> 
> On Tue, Aug 08, 2006 at 06:48:31PM +0200, Takashi Iwai wrote:
> > What we need next is to write up a code to communicate with ADC chip.
> > It could be merged into i2c/other/ak4xxx-adda.c, but it could be a
> > standlone implementation as found in aureon.c.
> 
> Is the last argument (mask) for AK_COMPOSE the maximum allowed mixer
> value?  Is it ok if this is not a power of two?

Yes and yes.


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: GPIO connections for the M-Audio Revolution 5.1

[Jochen Voss]

[-- Attachment #1.1: Type: text/plain, Size: 1792 bytes --]

Hello Takashi,

On Tue, Aug 08, 2006 at 07:30:44PM +0200, Takashi Iwai wrote:
> > Is the last argument (mask) for AK_COMPOSE the maximum allowed mixer
> > value?  Is it ok if this is not a power of two?
> 
> Yes and yes.

Fine.  Slowly I am getting there.  Now I have something working,
which uses the following addition to snd_akm4xxx_build_controls:

	if (ak->type == SND_AK5365) {
		memset(ctl, 0, sizeof(*ctl));
		if (ak->channel_names == NULL) {
			strcpy(ctl->id.name, "ADC Volume");
		} else {
			strcpy(ctl->id.name, ak->channel_names[0]);
		}
		ctl->id.index = ak->idx_offset * 2;
		ctl->id.iface = SNDRV_CTL_ELEM_IFACE_MIXER;
		ctl->count = 1;
		ctl->info = snd_akm4xxx_stereo_volume_info;
		ctl->get = snd_akm4xxx_stereo_volume_get;
		ctl->put = snd_akm4xxx_stereo_volume_put;
		/* register 4 & 5 */
		ctl->private_value =
			AK_COMPOSE(0, 4, 0, 0x98);
		ctl->private_data = ak;
		err = snd_ctl_add(ak->card,
				  snd_ctl_new(ctl, SNDRV_CTL_ELEM_ACCESS_READ|
					      SNDRV_CTL_ELEM_ACCESS_WRITE));
		
		if (err < 0)
			goto __error;

		idx += 2;	/* always stereo */
	}

(I will post a complete patch later today.)

This gives me a beautiful (and working!) volume slider for the capture
channel.  Does this look ok to you?  The magic constant 0x98 is from
page 35 of the spec and I think is correct.  I did not imitate the
loop over idx which other parts of this function have.  I hope that
this is ok.

The card seems to have a separate mute control.  How do I create a
mixer element for this?  I would like alsamixer to place a little mute
box just under the slider bar.  I looked around, but could not find
anything similar to copy within the ice1723 directory.

Many thanks for your help,
Jochen
-- 
http://seehuhn.de/

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: GPIO connections for the M-Audio Revolution 5.1

[Takashi Iwai]

At Tue, 8 Aug 2006 18:47:42 +0100,
Jochen Voss wrote:
> 
> Hello Takashi,
> 
> On Tue, Aug 08, 2006 at 07:30:44PM +0200, Takashi Iwai wrote:
> > > Is the last argument (mask) for AK_COMPOSE the maximum allowed mixer
> > > value?  Is it ok if this is not a power of two?
> > 
> > Yes and yes.
> 
> Fine.  Slowly I am getting there.  Now I have something working,
> which uses the following addition to snd_akm4xxx_build_controls:
> 
> 	if (ak->type == SND_AK5365) {
> 		memset(ctl, 0, sizeof(*ctl));
> 		if (ak->channel_names == NULL) {
> 			strcpy(ctl->id.name, "ADC Volume");
> 		} else {
> 			strcpy(ctl->id.name, ak->channel_names[0]);
> 		}
> 		ctl->id.index = ak->idx_offset * 2;
> 		ctl->id.iface = SNDRV_CTL_ELEM_IFACE_MIXER;
> 		ctl->count = 1;
> 		ctl->info = snd_akm4xxx_stereo_volume_info;
> 		ctl->get = snd_akm4xxx_stereo_volume_get;
> 		ctl->put = snd_akm4xxx_stereo_volume_put;
> 		/* register 4 & 5 */
> 		ctl->private_value =
> 			AK_COMPOSE(0, 4, 0, 0x98);
> 		ctl->private_data = ak;
> 		err = snd_ctl_add(ak->card,
> 				  snd_ctl_new(ctl, SNDRV_CTL_ELEM_ACCESS_READ|
> 					      SNDRV_CTL_ELEM_ACCESS_WRITE));
> 		
> 		if (err < 0)
> 			goto __error;
> 
> 		idx += 2;	/* always stereo */
> 	}
> 
> (I will post a complete patch later today.)
> 
> This gives me a beautiful (and working!) volume slider for the capture
> channel.  Does this look ok to you?  The magic constant 0x98 is from
> page 35 of the spec and I think is correct.  I did not imitate the
> loop over idx which other parts of this function have.  I hope that
> this is ok.

Great it looks almost fine.  Just a cosmetic thing:  remove superflous
parentheses around the single if () line (strcpy...).  It's a
convention of kernel codes.

For a magic number 0x98, put a short comment there.

Maybe you should rename it to "Capture Volume" from "ADC Volume".
Or, pass "Capture Volume" from the caller side.
This is more common name.  The "ADC" and "DAC" strings are used
there for the multi-channel boards.  But Revo has only a stereo.

> The card seems to have a separate mute control.  How do I create a
> mixer element for this?  I would like alsamixer to place a little mute
> box just under the slider bar.  I looked around, but could not find
> anything similar to copy within the ice1723 directory.

Then you need to create a boolean switch.
The code would be something like below:


static int ak4xxx_switch_info(struct snd_kcontrol *kcontrol,
		struct snd_ctl_elem_info *uinfo)
{
	uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
	uinfo->count = 2;
	uinfo->value.integer.min = 0;
	uinfo->value.integer.max = 1;
	return 0;
}

static int ak4xxx_switch_get(struct snd_kcontrol *kcontrol,
		struct snd_ctl_elem_value *ucontrol)
{
	struct snd_akm4xxx *ak = snd_kcontrol_chip(kcontrol);
	...
	unsigned char val = snd_akm4xxx_get(ak, chip, addr);
	
	/* 0 = off, 1 = on */
	ucontrol->value.integer.value[0] = (val & left_bit) != 0;
	ucontrol->value.integer.value[1] = (val & right_bit) != 0;
	return 0;
}

static int ak4xxx_switch_put(struct snd_kcontrol *kcontrol,
		struct snd_ctl_elem_value *ucontrol)
{
	struct snd_akm4xxx *ak = snd_kcontrol_chip(kcontrol);
	...
	unsigned char val, oval;
	int change = 0;

	val = 0;
	if (ucontrol->value.integer.value[0])
		val |= left_bit;
	if (ucontrol->value.integer.value[1])
		val |= right_bit;
	oval = snd_akm4xxx_get(ak, chip, addr);
	change = (oval != val);
	if (change)
		snd_akm4xxx_put(ak, chip, addr, val);
	return change;
}


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