Some Patches for emu10k1

Some Patches for emu10k1

[Joachim Falk]

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

Hi Alsa-Devel List,

This are copies from 2 E-Mail messages I sent directly to
Jaroslav Kysela <perex@suse.cz>perex@suse.cz . I Have gotten
no reply so I assume I have been filtered out or have been
ignored because this is not the approved method of sending
patches. I hope sending patches to alsa-devel list is ok.
Following now the 2 patches for emu10k1.

-------- Original Message --------
Subject: Kernel OOPS in EMU10K1 Driver
Date: Mon, 31 May 2004 16:01:22 +0200
From: Joachim Falk <joachim@jfalk.easynet.de>
To: Jaroslav Kysela <perex@suse.cz>

Hey Jaroslav,

attached is patch to fix an kernel oops in "emusfx.c". The oops is
triggerable by executing following command:

#> lo10k1 --ctrl t-delta:1,t-cosx:1 -a sine.emu10k1.

Reason for the kernel oops is an out of bound condition on min/max of
the control value with regard to the size of the translation tables.

Additionally I have noticed that snd_emu10k1_verify_controls is used to
verify the controls passed from user mode. But the copy from user space
is discarded and later another copy from user space is done. This can
lead to race conditions where the user process changes the control after
the kernel has done a verify.

PS.: I have discroverd the oops while trying to get a better mixer for
my Soundblaster 5.1 . Any and all tips how to use your ld10k1 and lo10k1
tools will be greatly appreciated. At the moment I try to verify my
input and optput ports by outputing the sine.emu10k1 to various outputs
of the card.

MfG
Joachim Falk
------ End Original Message ------

-------- Original Message --------
Subject: And another fix this time for ld10k1
Date: Mon, 31 May 2004 20:15:44 +0200
From: Joachim Falk <joachim@jfalk.easynet.de>
To: Jaroslav Kysela <perex@suse.cz>

Hey Jaroslav,

attached is patch to fix accept_comm function for ld10k1.
Third parameter of accept syscall is inout.

MfG
Joachim Falk
------ End Original Message ------

The following is a question I asked on IRC channel
#creative at freenode.net but got no answer. Maybe someone
here is better equipped to answer my questions.

18:22 < joachim> Good evening to you all
18:24 < joachim> Well i am searching for good documentation about the
emu10k1 chip, is there something like a datasheet for this chip ?
18:24 < joachim> I haven't found one with google and searching on
creative.com was negative too
18:25 < joachim> Im especially interested in how the FX Busses work and
what the pcm send routing in the alsa mixer does
18:26 < joachim> The datasheet for the STA9708 AC97 Codec I have found
and it explains a lot of the mixer controls.
18:28 < joachim> I have found
http://people.freenet.de/kxdev/docs/original/emu10k1-overview.pdf and
http://people.freenet.de/kxdev/docs/original/fx8010-arch.pdf
18:28 < joachim> But there is still so much info missing here :-(

I am especcially interested what this emu10k1 registers do.

#define CPF			0x00		/* Current pitch and fraction register			*/
#define CPF_CURRENTPITCH_MASK	0xffff0000	/* Current pitch (linear,
0x4000 == unity pitch shift) 	*/
#define CPF_CURRENTPITCH	0x10100000
#define CPF_STEREO_MASK		0x00008000	/* 1 = Even channel interleave, odd
channel locked	*/
#define CPF_STOP_MASK		0x00004000	/* 1 = Current pitch forced to 0			*/
#define CPF_FRACADDRESS_MASK	0x00003fff	/* Linear fractional address of
the current channel	*/

#define PTRX			0x01		/* Pitch target and send A/B amounts register		*/
#define PTRX_PITCHTARGET_MASK	0xffff0000	/* Pitch target of specified
channel			*/
#define PTRX_PITCHTARGET	0x10100001
#define PTRX_FXSENDAMOUNT_A_MASK 0x0000ff00	/* Linear level of channel
output sent to FX send bus A	*/
#define PTRX_FXSENDAMOUNT_A	0x08080001
#define PTRX_FXSENDAMOUNT_B_MASK 0x000000ff	/* Linear level of channel
output sent to FX send bus B	*/
#define PTRX_FXSENDAMOUNT_B	0x08000001

#define CVCF			0x02		/* Current volume and filter cutoff register		*/
#define CVCF_CURRENTVOL_MASK	0xffff0000	/* Current linear volume of
specified channel		*/
#define CVCF_CURRENTVOL		0x10100002
#define CVCF_CURRENTFILTER_MASK	0x0000ffff	/* Current filter cutoff
frequency of specified channel	*/
#define CVCF_CURRENTFILTER	0x10000002

#define VTFT			0x03		/* Volume target and filter cutoff target register	*/
#define VTFT_VOLUMETARGET_MASK	0xffff0000	/* Volume target of
specified channel			*/
#define VTFT_VOLUMETARGET	0x10100003
#define VTFT_FILTERTARGET_MASK	0x0000ffff	/* Filter cutoff target of
specified channel		*/
#define VTFT_FILTERTARGET	0x10000003

#define PSST			0x06		/* Send C amount and loop start address register	*/
#define PSST_FXSENDAMOUNT_C_MASK 0xff000000	/* Linear level of channel
output sent to FX send bus C	*/

#define PSST_FXSENDAMOUNT_C	0x08180006

#define PSST_LOOPSTARTADDR_MASK	0x00ffffff	/* Loop start address of the
specified channel		*/
#define PSST_LOOPSTARTADDR	0x18000006

#define DSL			0x07		/* Send D amount and loop start address register	*/
#define DSL_FXSENDAMOUNT_D_MASK	0xff000000	/* Linear level of channel
output sent to FX send bus D	*/

#define DSL_FXSENDAMOUNT_D	0x08180007

#define DSL_LOOPENDADDR_MASK	0x00ffffff	/* Loop end address of the
specified channel		*/
#define DSL_LOOPENDADDR		0x18000007
#define FXRT_CHANNELA		0x000f0000	/* Effects send bus number for
channel's effects send A	*/
#define FXRT_CHANNELB		0x00f00000	/* Effects send bus number for
channel's effects send B	*/
#define FXRT_CHANNELC		0x0f000000	/* Effects send bus number for
channel's effects send C	*/
#define FXRT_CHANNELD		0xf0000000	/* Effects send bus number for
channel's effects send D	*/

I assume they are per emu10k1 channel (there are 64 of them ?).
I think I have understood that for each PCM output stream one of this
channels is used (For mono 1 for stereo 2). This channels can also be
used for wavetable synthesis.

And than this magic send routing decides in which FX buses the processed
stream will be targeted. Maximal 4 FX buses chan be selected per channel
? Send bus A,B,C, and D. Is this sendbus the same for each channel or
can it be configured for each channel seperatly. Is it fixed or can for
all channels globally be configured what FX bus sendbus A,B,C and D is ?

In the emu10k1 dsp I can than read from this FX buses and do effects on
them, outputs can than be written to output registsers of the dsp.
But some FX buses seam to be connected to outputs even if there is no
code in the dsp. Is that hardcoded in hardware or configurable and if
yes where ?

-- 
Joachim Falk <Joachim.Falk@gmx.de>

You can always tell a really good idea by the enemies it makes.
    --programmers' axiom


[-- Attachment #1.2: ld10k1-accept.patch --]
[-- Type: text/x-patch, Size: 579 bytes --]

diff -urN --exclude '*~' --exclude '*.o' --exclude '*.swp' --exclude 'config.*' --exclude .deps --exclude 'Makefile*' --exclude 'stamp*' --exclude tags --exclude dl10k1 --exclude ld10k1 --exclude lo10k1 ld10k1-0.1.3p1.orig/comm.c ld10k1-0.1.3p1/comm.c
--- ld10k1-0.1.3p1.orig/comm.c	2004-03-13 15:55:07.000000000 +0100
+++ ld10k1-0.1.3p1/comm.c	2004-05-31 18:09:25.000000000 +0200
@@ -127,7 +127,7 @@
 int accept_comm(int conn_num)
 {
 	struct sockaddr addr;
-	socklen_t addr_len;
+	socklen_t addr_len = sizeof(addr);
 	int sock;
 	
 	sock = accept(conn_num, &addr, &addr_len);


[-- Attachment #1.3: emu10k1-oops.patch --]
[-- Type: text/x-patch, Size: 1441 bytes --]

diff -urN --exclude '*~' --exclude '*.o' --exclude '*.ko' --exclude tags sound/pci/emu10k1.orig/emufx.c sound/pci/emu10k1/emufx.c
--- sound/pci/emu10k1.orig/emufx.c	2004-05-29 22:04:44.000000000 +0200
+++ sound/pci/emu10k1/emufx.c	2004-05-30 18:27:11.000000000 +0200
@@ -980,9 +980,29 @@
 			nctl.value[j] = ~gctl.value[j];	/* inverted, we want to write new value in gpr_ctl_put() */
 			val->value.integer.value[j] = gctl.value[j];
 		}
-		nctl.min = gctl.min;
-		nctl.max = gctl.max;
 		nctl.translation = gctl.translation;
+		switch (nctl.translation) {
+		case EMU10K1_GPR_TRANSLATION_TABLE100:
+			nctl.min = max(gctl.min, (unsigned int) 0);
+			nctl.max = min(gctl.max,sizeof(db_table)/sizeof(db_table[0])-1);
+			break;
+		case EMU10K1_GPR_TRANSLATION_BASS:
+			nctl.min = max(gctl.min, (unsigned int) 0);
+			nctl.max = min(gctl.max,sizeof(bass_table)/sizeof(bass_table[0])-1);
+			break;
+		case EMU10K1_GPR_TRANSLATION_TREBLE:
+			nctl.min = max(gctl.min, (unsigned int) 0);
+			nctl.max = min(gctl.max,sizeof(treble_table)/sizeof(treble_table[0])-1);
+			break;
+		case EMU10K1_GPR_TRANSLATION_ONOFF:
+			nctl.min = max(gctl.min, (unsigned int) 0);
+			nctl.max = min(gctl.max,sizeof(onoff_table)/sizeof(onoff_table[0])-1);
+			break;
+		default:
+			nctl.min = gctl.min;
+			nctl.max = gctl.max;
+			break;
+		}
 		if (ctl == NULL) {
 			ctl = (snd_emu10k1_fx8010_ctl_t *)kmalloc(sizeof(*ctl), GFP_KERNEL);
 			if (ctl == NULL)


[-- Attachment #1.4: oops.txt --]
[-- Type: text/plain, Size: 1479 bytes --]

Unable to handle kernel paging request at virtual address f09c0de4
 printing eip:
e1dcf947
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU:    0
EIP:    0060:[<e1dcf947>]    Not tainted
EFLAGS: 00010093   (2.6.6)
EIP is at snd_emu10k1_gpr_ctl_put+0xe7/0x1e0 [snd_emu10k1]
eax: 00000001   ebx: db82dc5c   ecx: 03afa691   edx: 00000000
esi: c6584460   edi: 00000001   ebp: d6dcbd04   esp: d6dcbcd4
ds: 007b   es: 007b   ss: 0068
Process ld10k1 (pid: 5544, threadinfo=d6dca000 task=d6acb1f0)
Stack: 00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000286
       ddb8c000 dcd4e278 c6584460 db82dd1c d6dcbf20 e1dd0e2e c6584460 dcd4e278
       000000f4 db82dc5c 0806d3c4 00000001 00000002 00000000 00000000 d6dcbe24
Call Trace:
 [<e1dd0e2e>] snd_emu10k1_add_controls+0x1fe/0x2e0 [snd_emu10k1]
 [<e1dcf7c0>] snd_emu10k1_gpr_ctl_info+0x0/0x50 [snd_emu10k1]
 [<e1dcf810>] snd_emu10k1_gpr_ctl_get+0x0/0x50 [snd_emu10k1]
 [<e1dcf860>] snd_emu10k1_gpr_ctl_put+0x0/0x1e0 [snd_emu10k1]
 [<e1dd1212>] snd_emu10k1_icode_poke+0xc2/0x140 [snd_emu10k1]
 [<e1dd6580>] snd_emu10k1_fx8010_ioctl+0x0/0x5e0 [snd_emu10k1]
 [<e1dd6974>] snd_emu10k1_fx8010_ioctl+0x3f4/0x5e0 [snd_emu10k1]
 [<e1dd6580>] snd_emu10k1_fx8010_ioctl+0x0/0x5e0 [snd_emu10k1]
 [<e1cc5697>] snd_hwdep_ioctl+0x47/0xd0 [snd_hwdep]
 [<c0162722>] sys_ioctl+0x112/0x2b0
 [<c0105d3f>] syscall_call+0x7/0xb

Code: 8b 04 8d a0 73 dd e1 89 44 24 0c eb 9c 8b 43 0c be cd cc cc
 <6>note: ld10k1[5544] exited with preempt_count 2


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Some Patches for emu10k1

[Peter Zubaj]

>Subject: And another fix this time for ld10k1
>Date: Mon, 31 May 2004 20:15:44 +0200
>From: Joachim Falk <joachim@jfalk.easynet.de>
>To: Jaroslav Kysela <perex@suse.cz>
>
>Hey Jaroslav,
>
>attached is patch to fix accept_comm function for ld10k1.
>Third parameter of accept syscall is inout.

Everything about ld10k1/lo10k1 should be routed to me
pzad@pobox.sk

>The following is a question I asked on IRC channel

AFAIK there is no other documentation. (best is driver source)

>I am especcially interested what this emu10k1 registers do. 

They are mostly used in midi synth, some of them are exported as mixer
controls.

>I assume they are per emu10k1 channel (there are 64 of them ?).
>I think I have understood that for each PCM output stream one of this
>channels is used (For mono 1 for stereo 2). This channels can also be
>used for wavetable synthesis. 

Not exactly (as I read on alsa-devel mailing list).
for mono PCM stream 2 channels are used
for stereo PCM stream 3 channels are used
but from user point of view it doesn't metter.

>And than this magic send routing decides in which FX buses the
>processed
>stream will be targeted. Maximal 4 FX buses chan be selected per
>channel
>? Send bus A,B,C, and D. Is this sendbus the same for each channel
>or can it be configured for each channel seperatly. Is it fixed
> or can for
>all channels globally be configured what FX bus sendbus A,B,C and
> D is ? 

Maybe this helps you:
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg11671.html

Can be configured via
EMU10K1 PCM Volume
EMU10K1 PCM Send Routing
EMU10K1 PCM Send Volume
controls.

>But some FX buses seam to be connected to outputs even if there is no
>code in the dsp. Is that hardcoded in hardware or configurable and if
>yes where ?

This is maybe hardware feature or ld10k1 bug. If you connect FX bus
0,1 to AC97 PCM output I think it will stop to do this.

Peter Zubaj
____________________________________
http://www.pobox.sk/ - najvacsi slovensky freemail





-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: Some Patches for emu10k1

[Takashi Iwai]

At Mon, 07 Jun 2004 23:14:20 +0200,
Joachim Falk wrote:
>
> Hi Alsa-Devel List,
> 
> This are copies from 2 E-Mail messages I sent directly to
> Jaroslav Kysela <perex@suse.cz>perex@suse.cz . I Have gotten
> no reply so I assume I have been filtered out or have been
> ignored because this is not the approved method of sending
> patches. I hope sending patches to alsa-devel list is ok.
> Following now the 2 patches for emu10k1.

The patch looks ok.  But I think nctl.min/max should be set to the
constant values (of array size) uncoditionally if the pre-defined
translation type is used.

Comments?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: Some Patches for emu10k1

[Joachim Falk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Zubaj wrote:
|Joachim Falk wrote:
|>The following is a question I asked on IRC channel
|
| AFAIK there is no other documentation. (best is driver source)
How inconvenient.
|>I am especcially interested what this emu10k1 registers do.

| They are mostly used in midi synth, some of them are exported as mixer
| controls.
That I allready did assume, nice to know for good. But I selected this
registeres especially because I assumed they where the ones responsible
for PCM send routing and some could be used to control the amplitude
which witch the channel is transmited to the FX Channels.

Ok after some more driver research and expirimentation I can say
that all following registers are per channel (There are 64 of them in
the EMU10K1).

#define FXRT			0x0b		/* Effects send routing register			*/
						/* NOTE: It is illegal to assign the same routing to	*/
						/* two effects sends.					*/
#define FXRT_CHANNELA		0x000f0000	/* Effects send bus number for
channel's effects send A	*/
#define FXRT_CHANNELB		0x00f00000	/* Effects send bus number for
channel's effects send B	*/
#define FXRT_CHANNELC		0x0f000000	/* Effects send bus number for
channel's effects send C	*/
#define FXRT_CHANNELD		0xf0000000	/* Effects send bus number for
channel's effects send D	*/

With FXRT one can select 4 destination FX buses for the channel data to
be send to. But they must all be different ones or the FX bus which
appears more than once in FXRT won't receive any data.

Control is 'EMU10K1 PCM Send Routing' it has 12 Values
#00: FX Target A, if the corresponding PCM stream is a mono
#01: FX Target B, if the corresponding PCM stream is a mono
#02: FX Target C, if the corresponding PCM stream is a mono
#03: FX Target D, if the corresponding PCM stream is a mono
#04: FX Target A for left, if the corresponding PCM stream is stereo
#05: FX Target B for left, if the corresponding PCM stream is stereo
#06: FX Target C for left, if the corresponding PCM stream is stereo
#07: FX Target D for left, if the corresponding PCM stream is stereo
#08: FX Target A for right, if the corresponding PCM stream is stereo
#09: FX Target B for right, if the corresponding PCM stream is stereo
#10: FX Target C for right, if the corresponding PCM stream is stereo
#11: FX Target D for right, if the corresponding PCM stream is stereo

amixer sset 'EMU10K1 PCM Send Routing',0 \
#0,#1,#2,#3,#4,#5,#6,#7,#8,#9,#10,#11,#12

#define VTFT			0x03		/* Volume target and filter cutoff target register	*/
#define VTFT_VOLUMETARGET_MASK	0xffff0000	/* Volume target of
specified channel			*/
#define VTFT_VOLUMETARGET	0x10100003

Than there is the VTFT register which acts as a master volum slider for
this channel.

Control is 'EMU10K1 PCM Volume' it has 3 Values
#0: Volume, if the corresponding PCM stream is a mono stream
#1: Volume left, if the corresponding PCM stream is a stereo stream
#2: Volume right, if the corresponding PCM stream is a stereo stream

amixer sset 'EMU10K1 PCM',0 #0,#1,#2

#define PTRX			0x01		/* Pitch target and send A/B amounts register		*/
#define PTRX_FXSENDAMOUNT_A_MASK 0x0000ff00	/* Linear level of channel
output sent to FX send bus A	*/
#define PTRX_FXSENDAMOUNT_A	0x08080001
#define PTRX_FXSENDAMOUNT_B_MASK 0x000000ff	/* Linear level of channel
output sent to FX send bus B	*/
#define PTRX_FXSENDAMOUNT_B	0x08000001

#define PSST			0x06		/* Send C amount and loop start address register	*/
#define PSST_FXSENDAMOUNT_C_MASK 0xff000000	/* Linear level of channel
output sent to FX send bus C	*/

#define PSST_FXSENDAMOUNT_C	0x08180006

#define DSL			0x07		/* Send D amount and loop start address register	*/
#define DSL_FXSENDAMOUNT_D_MASK	0xff000000	/* Linear level of channel
output sent to FX send bus D	*/

#define DSL_FXSENDAMOUNT_D	0x08180007

Than there is the PTRX, PSST and DSL register which acts as a volume
slider for the individual FX targets.

Control is 'EMU10K1 PCM Send Volume' it has 12 Values
#00: FX Target A Volume, if the corresponding PCM stream is a mono
#01: FX Target B Volume, if the corresponding PCM stream is a mono
#02: FX Target C Volume, if the corresponding PCM stream is a mono
#03: FX Target D Volume, if the corresponding PCM stream is a mono
#04: FX Target A Volume left, if the corresponding PCM stream is stereo
#05: FX Target B Volume left, if the corresponding PCM stream is stereo
#06: FX Target C Volume left, if the corresponding PCM stream is stereo
#07: FX Target D Volume left, if the corresponding PCM stream is stereo
#08: FX Target A Volume right, if the corresponding PCM stream is stereo
#09: FX Target B Volume right, if the corresponding PCM stream is stereo
#10: FX Target C Volume right, if the corresponding PCM stream is stereo
#11: FX Target D Volume right, if the corresponding PCM stream is stereo

amixer sset 'EMU10K1 PCM Send',0 \
#0,#1,#2,#3,#4,#5,#6,#7,#8,#9,#10,#11,#12


|>I assume they are per emu10k1 channel (there are 64 of them ?).
|>I think I have understood that for each PCM output stream one of this
|>channels is used (For mono 1 for stereo 2). This channels can also be
|>used for wavetable synthesis.
|
| Not exactly (as I read on alsa-devel mailing list).
Do you have maybe a reference for this E-Mail message to
make searching in the archive of alsa-devel easier ?

| for mono PCM stream 2 channels are used
| for stereo PCM stream 3 channels are used
| but from user point of view it doesn't metter.
Hmm, yes A PCM stream is defined as such
struct _snd_emu10k1_pcm {
	emu10k1_t *emu;
	snd_emu10k1_pcm_type_t type;
	snd_pcm_substream_t *substream;
	emu10k1_voice_t *voices[2]; <-- This are the channles
	emu10k1_voice_t *extra;     <-- This are the channles
	unsigned short running;
	unsigned short first_ptr;
	snd_util_memblk_t *memblk;
	unsigned int start_addr;
	unsigned int ccca_start_addr;
	unsigned int capture_ipr;	/* interrupt acknowledge mask */
	unsigned int capture_inte;	/* interrupt enable mask */
	unsigned int capture_ba_reg;	/* buffer address register */
	unsigned int capture_bs_reg;	/* buffer size register */
	unsigned int capture_idx_reg;	/* buffer index register */
	unsigned int capture_cr_val;	/* control value */
	unsigned int capture_cr_val2;	/* control value2 (for audigy)*/
	unsigned int capture_bs_val;	/* buffer size value */
	unsigned int capture_bufsize;	/* buffer size in bytes */
};
I assume a second (for mono) or third (for stereo) channel is needed for
smooth switching of channels. If the data of an pcm chunk runs out on
one channel another is maybe preloaded with the next pcm chunk and can
promptly be activated.
Not sure here as I haven't looked at this part of the code just yet.
Corrections please !

|
|
|>And than this magic send routing decides in which FX buses the
|>processed
|>stream will be targeted. Maximal 4 FX buses chan be selected per
|>channel
|>? Send bus A,B,C, and D. Is this sendbus the same for each channel
|>or can it be configured for each channel seperatly. Is it fixed
|>or can for
|>all channels globally be configured what FX bus sendbus A,B,C and
|>D is ?
|
|
| Maybe this helps you:
| http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg11671.html
No unfortunately not. I allready found that one message, before asking
here, too.

| Can be configured via
| EMU10K1 PCM Volume
| EMU10K1 PCM Send Routing
| EMU10K1 PCM Send Volume
| controls.
|
|
|>But some FX buses seam to be connected to outputs even if there is no
|>code in the dsp. Is that hardcoded in hardware or configurable and if
|>yes where ?
|
|
| This is maybe hardware feature or ld10k1 bug. If you connect FX bus
| 0,1 to AC97 PCM output I think it will stop to do this.
This seams to be a hardware feature of the EMU10K1 I think because if
you clear the dsp code than FX bus channels 0,1 and 8,9 will be
forwarded to Output channels 0,1 and 8,9. This I can say for sure.
The others (2-7 and 10-15) I can not be sure because I have no speakers
on these channels or they are not connected to output on my card. But I
assume that to be the case too. As soon as you start driving an output
within your DSP code the forwarding seams to vanish. I think this can
not be a alsa driver feature because you can verify that the DSP really
is empty by catting /proc/asound/Live/fx8010_acode. So the alsa driver
has no possibility to magically insert some of its one forwardings if
none are programmed by the user.

|
| Peter Zubaj
| ____________________________________
| http://www.pobox.sk/ - najvacsi slovensky freemail
By the way, I try to fix myself a master slider for the Live.
But before I can do this I have to understand the EMU10k1 driver and
the alsa-libs a little bit more.

P.S.:
The amixer and alsamixer are horrible broken in regard to multivalue
controlls (>2).

Than there is the snafu that the Whole EMU10K1 controlls are inactive

static snd_kcontrol_new_t snd_emu10k1_send_routing_control =
{
	.access =	SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_INACTIVE,
~        .iface =        SNDRV_CTL_ELEM_IFACE_MIXER,
~        .name =         "EMU10K1 PCM Send Routing",
	.count =	32,
~        .info =         snd_emu10k1_send_routing_info,
~        .get =          snd_emu10k1_send_routing_get,
~        .put =          snd_emu10k1_send_routing_put
};

static snd_kcontrol_new_t snd_emu10k1_send_volume_control =
{
	.access =	SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_INACTIVE,
~        .iface =        SNDRV_CTL_ELEM_IFACE_MIXER,
~        .name =         "EMU10K1 PCM Send Volume",
	.count =	32,
~        .info =         snd_emu10k1_send_volume_info,
~        .get =          snd_emu10k1_send_volume_get,
~        .put =          snd_emu10k1_send_volume_put
};


static snd_kcontrol_new_t snd_emu10k1_attn_control =
{
	.access =	SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_INACTIVE,
~        .iface =        SNDRV_CTL_ELEM_IFACE_MIXER,
~        .name =         "EMU10K1 PCM Volume",
	.count =	32,
~        .info =         snd_emu10k1_attn_info,
~        .get =          snd_emu10k1_attn_get,
~        .put =          snd_emu10k1_attn_put
};

But amixer and alsamixer displays the first ones (index 0) anyway
it seams.
Or does something in the emu10k1 driver code enable the
control with index 0 ?

MfG
Joachim Falk
- --
You can always tell a really good idea by the enemies it makes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAz3WeKwZcgs55jUMRAtQAAKCL/dYs79ljfpCwwtAnONxzWRJWkQCfVP4u
IWi3RQZ0g7jW8aZwqa9ZB1Y=
=TXJe
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

[PATCH] fix for ac97->front speaker routing (was Re: Some Patches for emu10k1)

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

On Tue, 2004-06-15 at 18:18, Joachim Falk wrote:
> |>But some FX buses seam to be connected to outputs even if there is no
> |>code in the dsp. Is that hardcoded in hardware or configurable and if
> |>yes where ?
> |
> |
> | This is maybe hardware feature or ld10k1 bug. If you connect FX bus
> | 0,1 to AC97 PCM output I think it will stop to do this.
> This seams to be a hardware feature of the EMU10K1 I think because if
> you clear the dsp code than FX bus channels 0,1 and 8,9 will be
> forwarded to Output channels 0,1 and 8,9. This I can say for sure.
> The others (2-7 and 10-15) I can not be sure because I have no speakers
> on these channels or they are not connected to output on my card. But I
> assume that to be the case too. As soon as you start driving an output
> within your DSP code the forwarding seams to vanish. I think this can
> not be a alsa driver feature because you can verify that the DSP really
> is empty by catting /proc/asound/Live/fx8010_acode. So the alsa driver
> has no possibility to magically insert some of its one forwardings if
> none are programmed by the user.

I believe I have figured this out.  The following lines are taken from
8010.h in the kX Project SDK.  This file is basically the same as
emu10k1.h in the ALSA driver, with some interesting additions.  The
following lines are *not* present in the ALSA driver:

    // HCFG2 for 10k2: 0x18:
    #define HCFG_K2                 0x18
    // -- unknown; experiments only FIXME
    #define HCFG_K2_GPINPUT_MASK    0x0000ff00
    #define HCFG_K2_GPOUTPUT_MASK   0x000000ff
    #define HCFG_K2_DISABLE_ANALOG  0x40                    // = 'enable' for Audigy2 (chiprev=4)
    #define HCFG_K2_ENABLE_DIGITAL  0x04
    #define HCFG_K2_BYPASS          0x02                    // drive's internal bypass (?)
    #define HCFG_K2_UNKNOWN_20      0x20
    #define HCFG_K2_UNKNOWN_80      0x80                    // turn off ac97 front -> front (10k2.1)
    #define HCFG_K2_MULTIPURPOSE_JACK       0x2000          // center+swf+rear_center (a2/a2ex)
                                                            // + digital for generic 10k2
    #define HCFG_K2_DIGITAL_JACK    0x1000                  // digital for a2 platinum
    #define HCFG_K2_FRONT_JACK      0x4000
    #define HCFG_K2_REAR_JACK       0x8000
    #define HCFG_K2_PHONES_JACK     0x0100          // LiveDrive

    // outputs:
    //   for audigy2 platinum: 0xa00
    //   for a2 platinum ex: 0x1c00
    //   for a1 platinum: 0x0

It appears that HCFG_K2_UNKNOWN_80 is used to disable the ac97 front -> front 
output routing.

If you compare 8010.h to emu10k1.h, there are several ofthese places where gaps 
appear in the sequence of register values, and they have filled many of them in,
by reverse engineering.

I have attached a patch to add these defines to emu10k1.h, renaming the variables 
in keeping with the ALSA convention.  Please retain the lines that attribute this code 
to the kX project; I added this because there is a part of 8010.h which they copied 
from emu10k1.h (the DBG_ stuff), and they give credit to ALSA in the comments.

Lee




[-- Attachment #2: Type: text/x-patch, Size: 1669 bytes --]

Index: alsa-kernel/include/emu10k1.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/emu10k1.h,v
retrieving revision 1.41
diff -u -r1.41 emu10k1.h
--- alsa-kernel/include/emu10k1.h	23 Jun 2004 11:49:07 -0000	1.41
+++ alsa-kernel/include/emu10k1.h	26 Jun 2004 04:56:40 -0000
@@ -218,6 +218,32 @@
 						/* Should be set to 1 when the EMU10K1 is	*/
 						/* completely initialized.			*/
 
+/* the following A_HCFG_* lines (including comments) are taken from 8010.h in the kX driver SDK.*/
+
+// HCFG2 for 10k2: 0x18:
+#define A_HCFG                 0x18
+// -- unknown; experiments only FIXME
+#define A_HCFG_GPINPUT_MASK    0x0000ff00
+#define A_HCFG_GPOUTPUT_MASK   0x000000ff
+#define A_HCFG_DISABLE_ANALOG  0x40		/* 'enable' for Audigy2 (chiprev=4)		*/
+#define A_HCFG_ENABLE_DIGITAL  0x04
+#define A_HCFG_BYPASS          0x02		/* drive's internal bypass (?)			*/
+#define A_HCFG_UNKNOWN_20      0x20
+#define A_HCFG_UNKNOWN_80      0x80		/* turn off ac97 front -> front (10k2.1)	*/
+#define A_HCFG_MULTIPURPOSE_JACK       0x2000	/* center+swf+rear_center (a2/a2ex)		*/
+						/* + digital for generic 10k2			*/
+#define A_HCFG_DIGITAL_JACK    0x1000		/* digital for a2 platinum			*/
+#define A_HCFG_FRONT_JACK      0x4000
+#define A_HCFG_REAR_JACK       0x8000
+#define A_HCFG_PHONES_JACK     0x0100		/* LiveDrive					*/
+
+// outputs:
+//   for audigy2 platinum: 0xa00
+//   for a2 platinum ex: 0x1c00
+//   for a1 platinum: 0x0
+
+/* end section from kX driver									*/
+
 //For Audigy, MPU port move to 0x70-0x74 ptr register
 
 #define MUDATA			0x18		/* MPU401 data register (8 bits)       		*/

Re: [PATCH] fix for ac97->front speaker routing (was Re: Some Patches for emu10k1)

[James Courtier-Dutton]

Lee Revell wrote:
> On Tue, 2004-06-15 at 18:18, Joachim Falk wrote:
> 
>>|>But some FX buses seam to be connected to outputs even if there is no
>>|>code in the dsp. Is that hardcoded in hardware or configurable and if
>>|>yes where ?
>>|
>>|
>>| This is maybe hardware feature or ld10k1 bug. If you connect FX bus
>>| 0,1 to AC97 PCM output I think it will stop to do this.
>>This seams to be a hardware feature of the EMU10K1 I think because if
>>you clear the dsp code than FX bus channels 0,1 and 8,9 will be
>>forwarded to Output channels 0,1 and 8,9. This I can say for sure.
>>The others (2-7 and 10-15) I can not be sure because I have no speakers
>>on these channels or they are not connected to output on my card. But I
>>assume that to be the case too. As soon as you start driving an output
>>within your DSP code the forwarding seams to vanish. I think this can
>>not be a alsa driver feature because you can verify that the DSP really
>>is empty by catting /proc/asound/Live/fx8010_acode. So the alsa driver
>>has no possibility to magically insert some of its one forwardings if
>>none are programmed by the user.
> 
> 
> I believe I have figured this out.  The following lines are taken from
> 8010.h in the kX Project SDK.  This file is basically the same as
> emu10k1.h in the ALSA driver, with some interesting additions.  The
> following lines are *not* present in the ALSA driver:
> 

Have you actually tested changing those bits? Does it actually stop the 
AC97 output reaching the Front speakers?

I have been working on the AudigyLS driver that uses what I will call a 
P17 chip.

The Audigy 2 card has a P16V chip.
The P17 chip is quite similar to the P16V chip.

I have found that the general layout of the chips is that all inputs go 
into the P17 chip. The P17 chip then has some registers that adjust the 
volume of different routes.
For example. On the AudigyLS, all the input from the MIC or LINE IN goes 
via the PLAYBACK parts(not the CAPTURE) of the AC97 chip and into the 
Philips 24bit ADC.
MIC -> AC97 -> Analog link -> Philips 24bit ADC -> P17 -> P17 register 
volume control -> Front speakers.

The P17 then has a register that sets the volume for the ADC direct to 
Front speakers route. Most people will want the MIC to be recorded, and 
not be sent directly to the speakers, so I have set this route to muted.

I expect the Audigy 2 is much the same.
1) MIC -> AC97 -> Analog link -> Philips ADC -> P16V -> P16V register(a) 
volume control -> Front speakers.
2) CPU -> DMA access for EMU10k2 -> I2S digital link -> P16V -> P16V 
register(b) volume control -> Front speakers.
3) CPU -> DMA access for P16V -> P16V register(c) volume control -> 
Front speakers.

There are actually some special lines of code in the emu10k1_main.c:
/* Hacks for Alice3 to work independent of haP16V driver */
...

Those are setting up the "I2S digital link" for the Audigy2.

P16V register(a),(b) and (c) are probably different registers.

The default volume levels are all set at 0dB, so as the "hacks for 
Alice3" don't include register(a), one will by default get feedback from 
the MIC direct to the front speakers.

I have almost got enough information on the P16V now, in order to make 
use of it.
I have:
1) DMA control registers (They are the same for the P16V and P17).
2) Switching between 48khz and 96khz.
I still need:
1) Which bits to set to get the interrupts working.
2) Setting 24bit output mode.

Work so far on the P17
I still need:
1) Switching between 48khz and 96khz.
2) Setting 24bit output mode.
I already have:
1) DMA control registers.
2) Interrupts working.
3) Volume controls
4) Digital/Analog outputs.

Cheers
James


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com