All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Mikhail Ramendik <mr@ramendik.ru>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Compiling the newest code for testing?
Date: Fri, 07 Jan 2005 12:16:11 +0100	[thread overview]
Message-ID: <s5hu0ptwkuc.wl@alsa2.suse.de> (raw)
In-Reply-To: <200501070525.45603.mr@ramendik.ru>

[-- 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]);
 }
 

  reply	other threads:[~2005-01-07 11:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07  2:25 Compiling the newest code for testing? Mikhail Ramendik
2005-01-07 11:16 ` Takashi Iwai [this message]
2005-01-07 18:27   ` Mikhail Ramendik
2005-01-07 18:39     ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hu0ptwkuc.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=mr@ramendik.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.