From: Takashi Iwai <tiwai@suse.de>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: "Sven Köhler" <sven.koehler@gmail.com>,
"David Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org
Subject: Re: sound skipping regression introduced in 2.6.30-rc8
Date: Mon, 15 Jun 2009 10:30:01 +0200 [thread overview]
Message-ID: <s5h7hzdew6u.wl%tiwai@suse.de> (raw)
In-Reply-To: <200906121344.26139.bzolnier@gmail.com>
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@perex.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;
next prev parent reply other threads:[~2009-06-15 8:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-10 18:28 sound skipping regression introduced in 2.6.30-rc8 David Miller
2009-06-10 19:37 ` Takashi Iwai
2009-06-11 11:28 ` David Miller
2009-06-11 12:02 ` David Miller
2009-06-11 13:32 ` Bartlomiej Zolnierkiewicz
2009-06-11 13:56 ` Takashi Iwai
2009-06-11 14:14 ` Bartlomiej Zolnierkiewicz
2009-06-11 14:23 ` Takashi Iwai
2009-06-11 15:40 ` Bartlomiej Zolnierkiewicz
2009-06-11 16:07 ` Takashi Iwai
2009-06-11 17:36 ` Bartlomiej Zolnierkiewicz
2009-06-11 14:02 ` Takashi Iwai
2009-06-10 19:37 ` Sven Köhler
2009-06-11 0:58 ` Takashi Iwai
2009-06-11 6:47 ` Sven Köhler
2009-06-11 8:18 ` Takashi Iwai
2009-06-11 21:38 ` Sven Köhler
2009-06-12 1:52 ` Takashi Iwai
2009-06-12 11:44 ` Bartlomiej Zolnierkiewicz
2009-06-15 8:30 ` Takashi Iwai [this message]
2009-06-15 8:39 ` Takashi Iwai
2009-06-15 9:25 ` David Miller
2009-06-15 9:48 ` Takashi Iwai
2009-06-15 9:58 ` Takashi Iwai
2009-06-15 10:11 ` David Miller
2009-06-15 10:26 ` Takashi Iwai
2009-06-15 18:25 ` Sven Köhler
2009-06-15 19:15 ` Bartlomiej Zolnierkiewicz
2009-06-15 10:09 ` David Miller
2009-06-15 9:18 ` David Miller
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=s5h7hzdew6u.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=bzolnier@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sven.koehler@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).