lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5h7hzdew6u.wl%tiwai@suse.de>
Date:	Mon, 15 Jun 2009 10:30:01 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Sven Köhler <sven.koehler@...il.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: sound skipping regression introduced in 2.6.30-rc8

At Fri, 12 Jun 2009 13:44:25 +0200,
Bartlomiej Zolnierkiewicz wrote:
> 
> 
> On Friday 12 June 2009 03:52:48 Takashi Iwai wrote:
> > At Thu, 11 Jun 2009 23:38:17 +0200,
> > Sven Köhler wrote:
> > > 
> > > >>>> Can somebody point out, how I can set this xrun_debug thing or can
> > > >>>> somebody provide a patch that reverts the change?
> > > >>> Did you read my reply to David?
> > > >> I will try, what is described there and I will report back if I get any
> > > >> debug output.
> > > > 
> > > > Thanks, that'll be be helpful.
> > > 
> > > Below is the output. Note, that audacious 2.x was not only skipping a
> > > little bit. In fact, the clock that was showing the time of audio played
> > > was running twice as fast or even 4 times as fast. The sound was played
> > > at the right samplerate but in fast it seems, that much of the audio
> > > data was skipped and I only heard a series of short fragments of what
> > > should have been the song I'm listening to.
> > > 
> > > 
> > > PCM: hw_ptr skipping! (pos=4096, delta=7169, period=1024, jdelta=0/149)
> > 
> > OK, it must be the same problem indeed as David and Bartlomiej see.
> > 
> > Although Bartlomiej wrote that reverting the commit below didn't help,
> > I still suspect it comes from there.
> >      commit da2436a23c038055b1da6fe30b6ea2886b1e07b0
> >      Author: Jaroslav Kysela <perex@...ex.cz>
> >      Date:   Mon Apr 13 21:31:25 2009 +0200
> >      [ALSA] intel8x0: do not use zero value from PICB register
> > 
> > The below is a revised patch to fix the possible regression from this.
> > Could you guys give it a try, or check reverting the above?
> 
> The issue is still present with the revised patch.

I think we should go back to basic.  The patch below cuts off the
position compensation but falls back to the last value, which is a
safer option.  How about this?


thanks,

Takashi

---
diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c
index 173bebf..1c02705 100644
--- a/sound/pci/intel8x0.c
+++ b/sound/pci/intel8x0.c
@@ -356,8 +356,6 @@ struct ichdev {
         unsigned int position;
 	unsigned int pos_shift;
 	unsigned int last_pos;
-	unsigned long last_pos_jiffies;
-	unsigned int jiffy_to_bytes;
         int frags;
         int lvi;
         int lvi_frag;
@@ -844,7 +842,6 @@ static int snd_intel8x0_pcm_trigger(struct snd_pcm_substream *substream, int cmd
 	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 		val = ICH_IOCE | ICH_STARTBM;
 		ichdev->last_pos = ichdev->position;
-		ichdev->last_pos_jiffies = jiffies;
 		break;
 	case SNDRV_PCM_TRIGGER_SUSPEND:
 		ichdev->suspended = 1;
@@ -1048,7 +1045,6 @@ static int snd_intel8x0_pcm_prepare(struct snd_pcm_substream *substream)
 			ichdev->pos_shift = (runtime->sample_bits > 16) ? 2 : 1;
 	}
 	snd_intel8x0_setup_periods(chip, ichdev);
-	ichdev->jiffy_to_bytes = (runtime->rate * 4 * ichdev->pos_shift) / HZ;
 	return 0;
 }
 
@@ -1073,19 +1069,13 @@ static snd_pcm_uframes_t snd_intel8x0_pcm_pointer(struct snd_pcm_substream *subs
 		    ptr1 == igetword(chip, ichdev->reg_offset + ichdev->roff_picb))
 			break;
 	} while (timeout--);
+	ptr = ichdev->last_pos;
 	if (ptr1 != 0) {
 		ptr1 <<= ichdev->pos_shift;
 		ptr = ichdev->fragsize1 - ptr1;
 		ptr += position;
-		ichdev->last_pos = ptr;
-		ichdev->last_pos_jiffies = jiffies;
-	} else {
-		ptr1 = jiffies - ichdev->last_pos_jiffies;
-		if (ptr1)
-			ptr1 -= 1;
-		ptr = ichdev->last_pos + ptr1 * ichdev->jiffy_to_bytes;
-		ptr %= ichdev->size;
 	}
+	ichdev->last_pos = ptr;
 	spin_unlock(&chip->reg_lock);
 	if (ptr >= ichdev->size)
 		return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ