[alsa-devel] [PATCH] ALSA - HDA - Add period time constraint to hda-intel
As there is a 10 seconds schedule_timeout in alsa-kernel
The following error occur when aplay/arecord using a period time longer than 10 seconds for for those hda codec which support rate lower than 32000 when prealloc = 4096
ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x1aeb00, format=0x4111 ... ALSA pcm_native.c:1531: playback drain error (DMA or IRQ trouble?)
aplay -v -Dhw:1 --period-time=10001000 22050.wav Playing WAVE '22050.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Stereo Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 22050 exact rate : 22050 (22050/1) msbits : 16 buffer_size : 441024 period_size : 220512 period_time : 10000544 tstamp_mode : NONE period_step : 1 avail_min : 220512 period_event : 0 start_threshold : 441024 stop_threshold : 441024 silence_threshold: 0 silence_size : 0 boundary : 1806434304 appl_ptr : 0 hw_ptr : 0
ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x9c500, format=0x511 ALSA hda_codec.c:1295: hda_codec_setup_stream: NID=0x8, stream=0x1, channel=0, format=0x511 ALSA pcm_lib.c:1789: capture write error (DMA or IRQ trouble?)
arecord -Dhw:1 -v --period-time=10005000 -r 8000 -c2 -f S16_LE /dev/null Recording WAVE '/dev/null' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo Hardware PCM card 1 'HDA Intel' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 8000 exact rate : 8000 (8000/1) msbits : 16 buffer_size : 160064 period_size : 80032 period_time : 10004000 tstamp_mode : NONE period_step : 1 avail_min : 80032 period_event : 0 start_threshold : 1 stop_threshold : 160064 silence_threshold: 0 silence_size : 0 boundary : 1311244288 appl_ptr : 0 hw_ptr : 0 arecord: pcm_read:1773: read error: Input/output error
At Tue, 24 May 2011 12:15:05 +0800, Raymond Yau wrote:
As there is a 10 seconds schedule_timeout in alsa-kernel
The following error occur when aplay/arecord using a period time longer than 10 seconds for for those hda codec which support rate lower than 32000 when prealloc = 4096
ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x1aeb00, format=0x4111 ... ALSA pcm_native.c:1531: playback drain error (DMA or IRQ trouble?)
Wouldn't it be better to fix the PCM timeout itself? Does the patch below work?
thanks,
Takashi
--- diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index abfeff16..a754722 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1756,8 +1756,16 @@ static int wait_for_avail(struct snd_pcm_substream *substream, wait_queue_t wait; int err = 0; snd_pcm_uframes_t avail = 0; + long wait_time = 10; /* 10 seconds timeout as default */ long tout;
+ if (runtime->rate) { + long t = (runtime->period_size * 2 + runtime->rate - 1) / + runtime->rate; + wait_time = max(t, wait_time); + } + wait_time = msecs_to_jiffies(wait_time * 1000); + init_waitqueue_entry(&wait, current); add_wait_queue(&runtime->tsleep, &wait); for (;;) { @@ -1767,7 +1775,7 @@ static int wait_for_avail(struct snd_pcm_substream *substream, } set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream); - tout = schedule_timeout(msecs_to_jiffies(10000)); + tout = schedule_timeout(wait_time); snd_pcm_stream_lock_irq(substream); switch (runtime->status->state) { case SNDRV_PCM_STATE_SUSPENDED:
2011/5/24 Takashi Iwai tiwai@suse.de:
ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x1aeb00, format=0x4111 ... ALSA pcm_native.c:1531: playback drain error (DMA or IRQ trouble?)
Wouldn't it be better to fix the PCM timeout itself? Does the patch below work?
thanks,
Takashi
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index abfeff16..a754722 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1756,8 +1756,16 @@ static int wait_for_avail(struct snd_pcm_substream *substream, wait_queue_t wait; int err = 0; snd_pcm_uframes_t avail = 0;
- long wait_time = 10; /* 10 seconds timeout as default */
long tout;
- if (runtime->rate) {
- long t = (runtime->period_size * 2 + runtime->rate - 1) /
- runtime->rate;
- wait_time = max(t, wait_time);
- }
- wait_time = msecs_to_jiffies(wait_time * 1000);
init_waitqueue_entry(&wait, current); add_wait_queue(&runtime->tsleep, &wait); for (;;) { @@ -1767,7 +1775,7 @@ static int wait_for_avail(struct snd_pcm_substream *substream, } set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream);
- tout = schedule_timeout(msecs_to_jiffies(10000));
- tout = schedule_timeout(wait_time);
snd_pcm_stream_lock_irq(substream); switch (runtime->status->state) { case SNDRV_PCM_STATE_SUSPENDED:
you patch only fix the playback write/capture read error .
does it mean that even when the application (e.g. PA server) set stop_threshold to boundary can only freerun for 10 seconds only ?
The drain error in pcm_native.c still occur when application use a period time longer than 10 seconds and some of the audio signal at the end seem lost in snd_pcm_drain()
tout = schedule_timeout(10 * HZ);
...
if (tout == 0) { if (substream->runtime->status->state == SNDRV_PCM_STATE_SUSPENDED) result = -ESTRPIPE; else { snd_printd("playback drain error (DMA or IRQ trouble?)\n"); snd_pcm_stop(substream, SNDRV_PCM_STATE_SETUP); result = -EIO; } break; }
At Thu, 26 May 2011 10:01:14 +0800, Raymond Yau wrote:
2011/5/24 Takashi Iwai tiwai@suse.de:
ALSA hda_intel.c:1680: azx_pcm_prepare: bufsize=0x1aeb00, format=0x4111 ... ALSA pcm_native.c:1531: playback drain error (DMA or IRQ trouble?)
Wouldn't it be better to fix the PCM timeout itself? Does the patch below work?
thanks,
Takashi
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index abfeff16..a754722 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1756,8 +1756,16 @@ static int wait_for_avail(struct snd_pcm_substream *substream, wait_queue_t wait; int err = 0; snd_pcm_uframes_t avail = 0;
- long wait_time = 10; /* 10 seconds timeout as default */
long tout;
- if (runtime->rate) {
- long t = (runtime->period_size * 2 + runtime->rate - 1) /
- runtime->rate;
- wait_time = max(t, wait_time);
- }
- wait_time = msecs_to_jiffies(wait_time * 1000);
init_waitqueue_entry(&wait, current); add_wait_queue(&runtime->tsleep, &wait); for (;;) { @@ -1767,7 +1775,7 @@ static int wait_for_avail(struct snd_pcm_substream *substream, } set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream);
- tout = schedule_timeout(msecs_to_jiffies(10000));
- tout = schedule_timeout(wait_time);
snd_pcm_stream_lock_irq(substream); switch (runtime->status->state) { case SNDRV_PCM_STATE_SUSPENDED:
you patch only fix the playback write/capture read error .
does it mean that even when the application (e.g. PA server) set stop_threshold to boundary can only freerun for 10 seconds only ?
Yeah, this was overlooked. The patch below fixes both issues. Also it checks no_period_wakeup flag just to be sure (although setting this for normal read/write/drain operations doesn't make sense).
thanks,
Takashi
--- diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index abfeff16..f134130 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1756,8 +1756,18 @@ static int wait_for_avail(struct snd_pcm_substream *substream, wait_queue_t wait; int err = 0; snd_pcm_uframes_t avail = 0; - long tout; - + long wait_time, tout; + + if (runtime->no_period_wakeup) + wait_time = MAX_SCHEDULE_TIMEOUT; + else { + wait_time = 10; + if (runtime->rate) { + long t = runtime->period_size * 2 / runtime->rate; + wait_time = max(t, wait_time); + } + wait_time = msecs_to_jiffies(wait_time * 1000); + } init_waitqueue_entry(&wait, current); add_wait_queue(&runtime->tsleep, &wait); for (;;) { @@ -1765,9 +1775,8 @@ static int wait_for_avail(struct snd_pcm_substream *substream, err = -ERESTARTSYS; break; } - set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream); - tout = schedule_timeout(msecs_to_jiffies(10000)); + tout = schedule_timeout_interruptible(wait_time); snd_pcm_stream_lock_irq(substream); switch (runtime->status->state) { case SNDRV_PCM_STATE_SUSPENDED: diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 1a07750..b597408 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -1481,11 +1481,20 @@ static int snd_pcm_drain(struct snd_pcm_substream *substream, break; /* all drained */ init_waitqueue_entry(&wait, current); add_wait_queue(&to_check->sleep, &wait); - set_current_state(TASK_INTERRUPTIBLE); snd_pcm_stream_unlock_irq(substream); up_read(&snd_pcm_link_rwsem); snd_power_unlock(card); - tout = schedule_timeout(10 * HZ); + if (runtime->no_period_wakeup) + tout = MAX_SCHEDULE_TIMEOUT; + else { + tout = 10; + if (runtime->rate) { + long t = runtime->period_size * 2 / runtime->rate; + tout = max(t, tout); + } + tout = msecs_to_jiffies(tout * 1000); + } + tout = schedule_timeout_interruptible(tout); snd_power_lock(card); down_read(&snd_pcm_link_rwsem); snd_pcm_stream_lock_irq(substream);
2011/5/26 Takashi Iwai tiwai@suse.de:
At Thu, 26 May 2011 10:01:14 +0800,
Yeah, this was overlooked. The patch below fixes both issues. Also it checks no_period_wakeup flag just to be sure (although setting this for normal read/write/drain operations doesn't make sense).
Since aplay does not support no period wakeup mode
I can only confirm that your patch fix the read/write and drain when aplay using maximum period size/time of HDA codec (e.g. 11 seconds period time for 44100Hz when prealloc is 4096)
Not sure whether pulseaudio server still use maximum buffer size or not
but in pulsecore/sink.c and pulsecore/source.c
#define ABSOLUTE_MIN_LATENCY (500) #define ABSOLUTE_MAX_LATENCY (10*PA_USEC_PER_SEC) #define DEFAULT_FIXED_LATENCY (250*PA_USEC_PER_MSEC)
CPU usage jump from 2% to 12% when using
aplay -Dpulse --period-time=500 --buffer-time=1500 /usr/share/sounds/alsa/*.wav
although the sound is still good but PA server generate a huge amount of messages
participants (2)
-
Raymond Yau -
Takashi Iwai