Compiling the newest code for testing?

Compiling the newest code for testing?

[Mikhail Ramendik]

Hello,

I would like to do some extensive testing of alsa on my Intel 865PE hardware 
(notably the analog vs. SPDIF issues). I have done some bug reporting and 
tested some fixes (thanks go to Takashi) in the past, but then fell out of 
sync on kernel versions because of other kernel-related issues on my hardware 
(now finally resolved).

I would like to test the latest code, in order for this testing to be most 
useful.

But I really got lost in what is that newest code that I should test, and in 
how I should get it to run. So I have some questions:

- Which alsa code version is in the 2.6.10 kernel release? 
(include/sound/version.h says 1.0.6, but there seem to be changelog entries 
and factual changes even from 2.6.10-rc3...)

- Which alsa kernel code should I run for testing? The 2.6.10-kernel version? 
1.0.8rc2? CVS? 1.0.8rc2 plus some files from CVS [those related to i8x0]?

- Is it OK to compile this kernel code by merely copying the relevant 
directories (sound [except for sound/oss] and include/sound) from the alsa 
tree into the kernel tree? I run an RPM-based system, and would like to keep 
the existing approach to kernel building (full RPM rebuild) alive; it's slow 
but reliable. 

- Which alsa-lib and alsa-utils code should I be running? (I know how to 
compile it using RPM, I just need to understand the version).

And an i8x0-specific question: in the above-mentioned current code, should 
output to hw:0,0 go only to analog, or to both analog and spdif? 

-- 
Yours, Mikhail Ramendik



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Compiling the newest code for testing?

[Takashi Iwai]

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

At Fri, 7 Jan 2005 05:25:45 +0300,
Mikhail Ramendik wrote:
> 
> Hello,
> 
> I would like to do some extensive testing of alsa on my Intel 865PE hardware 
> (notably the analog vs. SPDIF issues). I have done some bug reporting and 
> tested some fixes (thanks go to Takashi) in the past, but then fell out of 
> sync on kernel versions because of other kernel-related issues on my hardware 
> (now finally resolved).
> 
> I would like to test the latest code, in order for this testing to be most 
> useful.
> 
> But I really got lost in what is that newest code that I should test, and in 
> how I should get it to run. So I have some questions:
> 
> - Which alsa code version is in the 2.6.10 kernel release? 
> (include/sound/version.h says 1.0.6, but there seem to be changelog entries 
> and factual changes even from 2.6.10-rc3...)

It's nearly 1.0.7, 1.0.6 plus fixes.

> - Which alsa kernel code should I run for testing? The 2.6.10-kernel version? 
> 1.0.8rc2? CVS? 1.0.8rc2 plus some files from CVS [those related to i8x0]?

For testing purpse, I recommend ALSA CVS version.
ATM, 1.0.8rc2 is very new, so it should be fine in most cases, too.

> - Is it OK to compile this kernel code by merely copying the relevant 
> directories (sound [except for sound/oss] and include/sound) from the alsa 
> tree into the kernel tree? I run an RPM-based system, and would like to keep 
> the existing approach to kernel building (full RPM rebuild) alive; it's slow 
> but reliable. 

Not always.  The ALSA cvs may contain the codes for the very latest
kernel (rc or mm).  Copying the files to kernel might not work when
the kernel function / API is changed.  The difference is usually
absorbed by patches in alsa-driver tree.

> - Which alsa-lib and alsa-utils code should I be running? (I know how to 
> compile it using RPM, I just need to understand the version).

It should match with the ALSA driver version.
The library itself has backward compatibility, but the configurations
included in alsa-lib package may not match with the old drivers.

> And an i8x0-specific question: in the above-mentioned current code, should 
> output to hw:0,0 go only to analog, or to both analog and spdif? 

Analog only.

Basically, you should avoid to access "hw:0,0".  If you want to output
to analog front, you can use "front", instead.  Similarly, for spdif,
use "spdif" (or "iec958").

Regarding the dubbed output to analog and spdif - I once had a patch
for testing but the tester couldn't apply it.  The latest patch is
attached below (to 1.0.8rc2 or CVS).  If you're interested in it,
please give it a try.


Takashi

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

Index: alsa-kernel/pci/intel8x0.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/intel8x0.c,v
retrieving revision 1.184
diff -u -r1.184 intel8x0.c
--- alsa-kernel/pci/intel8x0.c	5 Jan 2005 18:37:30 -0000	1.184
+++ alsa-kernel/pci/intel8x0.c	7 Jan 2005 11:13:43 -0000
@@ -355,7 +355,7 @@
 
 #define get_ichdev(substream) (ichdev_t *)(substream->runtime->private_data)
 
-typedef struct {
+typedef struct ichdev {
 	unsigned int ichd;			/* ich device number */
 	unsigned long reg_offset;		/* offset to bmaddr */
 	u32 *bdbar;				/* CPU address (32bit) */
@@ -380,6 +380,9 @@
 	unsigned int ali_slot;			/* ALI DMA slot */
 	struct ac97_pcm *pcm;
 	int pcm_open_flag;
+	struct ichdev *spdif_dev;
+	int slave_mode: 1;
+	int spdif_ok: 1;
 	unsigned int page_attr_changed: 1;
 } ichdev_t;
 
@@ -800,7 +803,8 @@
 	}
 	spin_unlock(&chip->reg_lock);
 	if (ack && ichdev->substream) {
-		snd_pcm_period_elapsed(ichdev->substream);
+		if (! ichdev->slave_mode)
+			snd_pcm_period_elapsed(ichdev->substream);
 	}
 	iputbyte(chip, port + ichdev->roff_sr,
 		 status & (ICH_FIFOE | ICH_BCIS | ICH_LVBCI));
@@ -843,10 +847,8 @@
  *  PCM part
  */
 
-static int snd_intel8x0_pcm_trigger(snd_pcm_substream_t *substream, int cmd)
+static int _snd_intel8x0_pcm_trigger(intel8x0_t *chip, ichdev_t *ichdev, int cmd)
 {
-	intel8x0_t *chip = snd_pcm_substream_chip(substream);
-	ichdev_t *ichdev = get_ichdev(substream);
 	unsigned char val = 0;
 	unsigned long port = ichdev->reg_offset;
 
@@ -878,6 +880,19 @@
 	return 0;
 }
 
+static int snd_intel8x0_pcm_trigger(snd_pcm_substream_t *substream, int cmd)
+{
+	intel8x0_t *chip = snd_pcm_substream_chip(substream);
+	ichdev_t *ichdev = get_ichdev(substream);
+	int err;
+	err = _snd_intel8x0_pcm_trigger(chip, ichdev, cmd);
+	if (err < 0)
+		return err;
+	if (ichdev->spdif_dev && ichdev->spdif_ok)
+		return _snd_intel8x0_pcm_trigger(chip, ichdev->spdif_dev, cmd);
+	return 0;
+}
+
 static int snd_intel8x0_ali_trigger(snd_pcm_substream_t *substream, int cmd)
 {
 	intel8x0_t *chip = snd_pcm_substream_chip(substream);
@@ -956,8 +971,14 @@
 	if (err >= 0) {
 		ichdev->pcm_open_flag = 1;
 		/* Force SPDIF setting */
-		if (ichdev->ichd == ICHD_PCMOUT && chip->spdif_idx < 0)
-			snd_ac97_set_rate(ichdev->pcm->r[0].codec[0], AC97_SPDIF, params_rate(hw_params));
+		if (ichdev->ichd == ICHD_PCMOUT) {
+			if (chip->spdif_idx < 0)
+				snd_ac97_set_rate(ichdev->pcm->r[0].codec[0],
+						  AC97_SPDIF, params_rate(hw_params));
+			else if (ichdev->spdif_dev)
+				ichdev->spdif_ok = ! snd_ac97_set_rate(ichdev->spdif_dev->pcm->r[0].codec[0],
+								       AC97_SPDIF, params_rate(hw_params));
+		}
 	}
 	return err;
 }
@@ -1045,6 +1066,19 @@
 		}
 	}
 	snd_intel8x0_setup_periods(chip, ichdev);
+	if (ichdev->spdif_dev && ichdev->spdif_ok) {
+		/* slave SPDIF DMA */
+		if (runtime->format != SNDRV_PCM_FORMAT_S16_LE ||
+		    runtime->channels != 2)
+			ichdev->spdif_ok = 0;
+		else {
+			ichdev_t *sdev = ichdev->spdif_dev;
+			sdev->physbuf = runtime->dma_addr;
+			sdev->size = snd_pcm_lib_buffer_bytes(substream);
+			sdev->fragsize = snd_pcm_lib_period_bytes(substream);
+			snd_intel8x0_setup_periods(chip, sdev);
+		}
+	}
 	spin_unlock_irq(&chip->reg_lock);
 	return 0;
 }
@@ -1162,6 +1196,13 @@
 		runtime->hw.formats |= SNDRV_PCM_FMTBIT_S32_LE;
 		snd_pcm_hw_constraint_msbits(runtime, 0, 32, 20);
 	}
+	if (chip->spdif_idx >= 0 && chip->device_type != DEVICE_ALI) {
+		if (! chip->ichd[chip->spdif_idx].substream) {
+			chip->ichd[chip->spdif_idx].slave_mode = 1;
+			chip->ichd[ICHD_PCMOUT].spdif_dev = &chip->ichd[chip->spdif_idx];
+			chip->ichd[ICHD_PCMOUT].spdif_ok = 0;
+		}
+	}
 	return 0;
 }
 
@@ -1169,6 +1210,10 @@
 {
 	intel8x0_t *chip = snd_pcm_substream_chip(substream);
 
+	if (chip->ichd[ICHD_PCMOUT].spdif_dev) {
+		chip->ichd[ICHD_PCMOUT].spdif_dev->slave_mode = 0;
+		chip->ichd[ICHD_PCMOUT].spdif_dev = NULL;
+	}
 	chip->ichd[ICHD_PCMOUT].substream = NULL;
 	return 0;
 }
@@ -1238,6 +1283,8 @@
 	intel8x0_t *chip = snd_pcm_substream_chip(substream);
 	int idx = chip->device_type == DEVICE_NFORCE ? NVD_SPBAR : ICHD_SPBAR;
 
+	if (chip->ichd[idx].slave_mode)
+		return -EBUSY;
 	return snd_intel8x0_pcm_open(substream, &chip->ichd[idx]);
 }
 

Re: Compiling the newest code for testing?

[Mikhail Ramendik]

You wrote:

> > - Which alsa kernel code should I run for testing? The 2.6.10-kernel
> > version? 1.0.8rc2? CVS? 1.0.8rc2 plus some files from CVS [those related
> > to i8x0]?
>
> For testing purpse, I recommend ALSA CVS version.
> ATM, 1.0.8rc2 is very new, so it should be fine in most cases, too.

OK, I'll do 1.0.8rc2, to avoid CVS-related issues.

> > - Is it OK to compile this kernel code by merely copying the relevant
> > directories (sound [except for sound/oss] and include/sound) from the
> > alsa tree into the kernel tree? I run an RPM-based system, and would like
> > to keep the existing approach to kernel building (full RPM rebuild)
> > alive; it's slow but reliable.
>
> Not always.  The ALSA cvs may contain the codes for the very latest
> kernel (rc or mm).  Copying the files to kernel might not work when
> the kernel function / API is changed.  The difference is usually
> absorbed by patches in alsa-driver tree.

Which kernel is 1.0.8rc2 for? There apparently is no recent -rc at the moment. 
If it's against an -mm version, I can compile that too, at least for the alsa 
tests. I just need to be sure which kernel version it's tied to.

And, will compiling ALSA separately resolve the kernel version vs. ALSA 
version issues? (I have read the INSTALL file and have questions, but I won't 
ask them until I'm sure this stuff will be needed; I'd really prefer to go 
with in-kernel compilation).
 
> > - Which alsa-lib and alsa-utils code should I be running? (I know how to
> > compile it using RPM, I just need to understand the version).
>
> It should match with the ALSA driver version.
> The library itself has backward compatibility, but the configurations
> included in alsa-lib package may not match with the old drivers.

OK, that's clear.

> > And an i8x0-specific question: in the above-mentioned current code,
> > should output to hw:0,0 go only to analog, or to both analog and spdif?
>
> Analog only.
>
> Basically, you should avoid to access "hw:0,0".  If you want to output
> to analog front, you can use "front", instead.  Similarly, for spdif,
> use "spdif" (or "iec958").

But OSS emulation is needed for some of the stuff I use, and that writes to 
hw:0,0 . I know I should be searching for fixed on the other end as well.

> Regarding the dubbed output to analog and spdif - I once had a patch
> for testing but the tester couldn't apply it.  The latest patch is
> attached below (to 1.0.8rc2 or CVS).  If you're interested in it,
> please give it a try.

I suspect I was that tester.

As soon as I get an alsa+kernel that works, I'll try the patch.

Thanks!

-- 
Yours, Mikhail Ramendik



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Compiling the newest code for testing?

[Takashi Iwai]

At Fri, 7 Jan 2005 21:27:38 +0300,
Mikhail Ramendik wrote:
> 
> > > - Is it OK to compile this kernel code by merely copying the relevant
> > > directories (sound [except for sound/oss] and include/sound) from the
> > > alsa tree into the kernel tree? I run an RPM-based system, and would like
> > > to keep the existing approach to kernel building (full RPM rebuild)
> > > alive; it's slow but reliable.
> >
> > Not always.  The ALSA cvs may contain the codes for the very latest
> > kernel (rc or mm).  Copying the files to kernel might not work when
> > the kernel function / API is changed.  The difference is usually
> > absorbed by patches in alsa-driver tree.
> 
> Which kernel is 1.0.8rc2 for? There apparently is no recent -rc at the moment. 
> If it's against an -mm version, I can compile that too, at least for the alsa 
> tests. I just need to be sure which kernel version it's tied to.

Basically, alsa-kernel is for the latest vanilla kernel.
Not sure whether it works with 2.6.10-mm tree now although I think it
should be fine, too.

> > > And an i8x0-specific question: in the above-mentioned current code,
> > > should output to hw:0,0 go only to analog, or to both analog and spdif?
> >
> > Analog only.
> >
> > Basically, you should avoid to access "hw:0,0".  If you want to output
> > to analog front, you can use "front", instead.  Similarly, for spdif,
> > use "spdif" (or "iec958").
> 
> But OSS emulation is needed for some of the stuff I use, and that writes to 
> hw:0,0 . I know I should be searching for fixed on the other end as well.

Then avoid OSS ;)

Or, you can assign hw:0,4 to /dev/adsp with a module option.
See OSS-Emulation.txt for details.


Takashi


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt