From: James Courtier-Dutton <James@superbug.demon.co.uk>
To: James Courtier-Dutton <James@superbug.demon.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>,
ALSA development <alsa-devel@alsa-project.org>
Subject: [PATCH] Fixes: Re: intel8x0 has stopped working.
Date: Mon, 02 Feb 2004 23:12:15 +0000 [thread overview]
Message-ID: <401ED94F.7080407@superbug.demon.co.uk> (raw)
In-Reply-To: <401EA82D.3060702@superbug.demon.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
James Courtier-Dutton wrote:
>
> Once thing I have noticed, is that with the alc650, we used to have VRA
> (alsa 0.9.8), but the 1.0.2 intel8x0 driver ignores the VRA and fixes
> itself at 48000.
> So, before I never needed the sample rate converters, but as it now
> fixes the rate at 48000, I need the sample rate converters, and they
> don't actually work.
>
>
I have found out what the problem is with the resamplers not working.
I was using: -
err = snd_pcm_sw_params_set_start_threshold(handle, swparams,
buffer_size); <- note buffer_size.
So, the state will stay in SND_PCM_STATE_PREPARED state until the buffer
is full.
Inside snd_pcm_write_areas() [in alsa-lib] we have a snd_pcm_wait
statement before we write frames into the buffer.
if (((snd_pcm_uframes_t)avail < pcm->avail_min && size >
(snd_pcm_uframes_t)avail) || (size >= pcm->xfer_align &&
(snd_pcm_uframes_t)avail < pcm->xfer_align)) {
then it calls snd_pcm_wait()
So, this will call snd_pcm_wait() until avail >= pcm->avail_min.
This will only become true if we are in SND_PCM_STATE_RUNNING state.
below the snd_pcm_wait(), we do try to execute snd_pcm_start() to get us
into SND_PCM_STATE_RUNNING, but this only gets executed if: -
if (state == SND_PCM_STATE_PREPARED && hw_avail >= (snd_pcm_sframes_t)
pcm->start_threshold) {
So, we will only reach a running state if the buffer is FULL, but the
buffer will NEVER become full, because of the previous snd_pcm_wait();
CATCH22!!!
I think a fix to this would be to limit as follows: -
start_threshold <= (buffer_size - avail_min)
I have fixed the issue for now, just by setting the "start_threshold" to
something other than buffer_size. But I think some work needs to be done
with alsa-lib to prevent this deadlock situation ever happening in alsa-lib.
From the application writers point of view, if the buffer is X bytes
long, and one used snd_pcm_writei() to write X+10 bytes, the buffer
should become full. Currently, that is not always the case, and alsa-lib
instead locks in snd_pcm_wait().
I attach a patch that fixes alsa-lib.
All it does it call snd_pcm_start() just before snd_pcm_wait() and due
to the if statement just above it, will only happen when the buffer is
going to be filled, therefore ensuring that even if "start_threshold" is
set too high, snd_pcm_start() will always be called if the buffer is
full, or about to become full.
Cheers
James
[-- Attachment #2: alsa-lib-lockup-fix.diff --]
[-- Type: text/x-patch, Size: 535 bytes --]
--- src/pcm/pcm.c.old 2004-02-02 23:07:14.355587424 +0000
+++ src/pcm/pcm.c 2004-02-02 23:07:19.871748840 +0000
@@ -6033,6 +6033,11 @@
} else if (((snd_pcm_uframes_t)avail < pcm->avail_min && size > (snd_pcm_uframes_t)avail) ||
(size >= pcm->xfer_align && (snd_pcm_uframes_t)avail < pcm->xfer_align)) {
+ if (state == SND_PCM_STATE_PREPARED ) {
+ err = snd_pcm_start(pcm);
+ if (err < 0)
+ goto _end;
+ }
if (pcm->mode & SND_PCM_NONBLOCK) {
err = -EAGAIN;
goto _end;
next prev parent reply other threads:[~2004-02-02 23:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-02 17:41 intel8x0 has stopped working James Courtier-Dutton
2004-02-02 17:59 ` Takashi Iwai
2004-02-02 19:34 ` Prakash K. Cheemplavam
2004-02-02 19:42 ` James Courtier-Dutton
2004-02-02 23:12 ` James Courtier-Dutton [this message]
2004-02-03 16:22 ` [PATCH] Fixes: " Jaroslav Kysela
2004-02-03 22:21 ` James Courtier-Dutton
2004-02-05 11:01 ` Jaroslav Kysela
2004-02-05 19:15 ` Glenn Maynard
2004-02-05 19:25 ` Takashi Iwai
2004-02-05 19:38 ` Jaroslav Kysela
2004-02-05 19:58 ` Glenn Maynard
2004-02-05 20:44 ` James Courtier-Dutton
2004-02-04 19:35 ` Takashi Iwai
2004-02-04 23:03 ` James Courtier-Dutton
2004-02-05 18:49 ` Takashi Iwai
2004-02-05 19:42 ` Takashi Iwai
2004-02-05 22:28 ` James Courtier-Dutton
2004-02-06 11:29 ` Takashi Iwai
2004-02-06 20:05 ` James Courtier-Dutton
2004-02-09 10:56 ` 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=401ED94F.7080407@superbug.demon.co.uk \
--to=james@superbug.demon.co.uk \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/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