[alsa-devel] device underruns
Hello,
I'm currently stress-testing my snd-usb-caiaq driver under several environments and happen to see a number of such messages echoed once in a while at the start of aplay (1.0.16):
underrun!!! (at least 1558380812.470 ms long) underrun!!! (at least 1558380818.673 ms long) underrun!!! (at least 1558380812.465 ms long)
Also, pulseaudio (0.9.14) keeps complaining with the following message all over the place:
E: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
What puzzles me a bit is that I don't really know where and how the driver could confuse the core so badly. All it reports is a valid pointer to the current head in each substream. Is there anything else it could provide for tighter syncing? Any hint how to debug this? Or maybe it's not a bug in this specific driver but in the core somewhere?
Thanks, Daniel
The posting below didn't get any response yet, but the problem persists. Any hints, anyone?
Thanks, Daniel
On Tue, Mar 31, 2009 at 04:46:03PM +0200, Daniel Mack wrote:
I'm currently stress-testing my snd-usb-caiaq driver under several environments and happen to see a number of such messages echoed once in a while at the start of aplay (1.0.16):
underrun!!! (at least 1558380812.470 ms long) underrun!!! (at least 1558380818.673 ms long) underrun!!! (at least 1558380812.465 ms long)
Also, pulseaudio (0.9.14) keeps complaining with the following message all over the place:
E: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
What puzzles me a bit is that I don't really know where and how the driver could confuse the core so badly. All it reports is a valid pointer to the current head in each substream. Is there anything else it could provide for tighter syncing? Any hint how to debug this? Or maybe it's not a bug in this specific driver but in the core somewhere?
Thanks, Daniel
At Sat, 25 Apr 2009 14:23:38 +0200, Daniel Mack wrote:
The posting below didn't get any response yet, but the problem persists. Any hints, anyone?
The ALSA PCM core just relies upon two things from the lowlevel driver:
1. The lowlevel driver calls snd_pcm_period_elapsed() at each time when the set-up period size has been processed by the hardware. 2. The pointer callback reports the sane position as the current position; not below the previous position and not above the next period boundary.
Especially pulseaudio is very sensitive about these two things, because it always asks the driver the current position. Thus, if your driver doesn't fulfill the above conditions, it won't work properly.
Takashi
Thanks, Daniel
On Tue, Mar 31, 2009 at 04:46:03PM +0200, Daniel Mack wrote:
I'm currently stress-testing my snd-usb-caiaq driver under several environments and happen to see a number of such messages echoed once in a while at the start of aplay (1.0.16):
underrun!!! (at least 1558380812.470 ms long) underrun!!! (at least 1558380818.673 ms long) underrun!!! (at least 1558380812.465 ms long)
Also, pulseaudio (0.9.14) keeps complaining with the following message all over the place:
E: module-alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Most likely this is an ALSA driver bug. Please report this issue to the PulseAudio developers.
What puzzles me a bit is that I don't really know where and how the driver could confuse the core so badly. All it reports is a valid pointer to the current head in each substream. Is there anything else it could provide for tighter syncing? Any hint how to debug this? Or maybe it's not a bug in this specific driver but in the core somewhere?
Thanks, Daniel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Sun, Apr 26, 2009 at 01:18:52PM +0200, Takashi Iwai wrote:
The posting below didn't get any response yet, but the problem persists. Any hints, anyone?
The ALSA PCM core just relies upon two things from the lowlevel driver:
- The lowlevel driver calls snd_pcm_period_elapsed() at each time when the set-up period size has been processed by the hardware.
- The pointer callback reports the sane position as the current position; not below the previous position and not above the next period boundary.
Especially pulseaudio is very sensitive about these two things, because it always asks the driver the current position. Thus, if your driver doesn't fulfill the above conditions, it won't work properly.
Oh well. Stupid me. I think I fixed it, and wonder why it didn't break more things. Could you apply the patch below?
Thanks, Daniel
diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c index 3f45c0f..b13ce76 100644 --- a/sound/usb/caiaq/audio.c +++ b/sound/usb/caiaq/audio.c @@ -195,11 +195,14 @@ static int snd_usb_caiaq_pcm_prepare(struct snd_pcm_substream *substream)
debug("%s(%p)\n", __func__, substream); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + dev->period_out_count[index] = BYTES_PER_SAMPLE + 1; dev->audio_out_buf_pos[index] = BYTES_PER_SAMPLE + 1; - else + } else { + dev->period_in_count[index] = BYTES_PER_SAMPLE; dev->audio_in_buf_pos[index] = BYTES_PER_SAMPLE; - + } + if (dev->streaming) return 0; @@ -300,8 +303,7 @@ static void check_for_elapsed_periods(struct snd_usb_caiaqdev *dev, if (!sub) continue;
- pb = frames_to_bytes(sub->runtime, - sub->runtime->period_size); + pb = snd_pcm_lib_period_bytes(sub); cnt = (sub->stream == SNDRV_PCM_STREAM_PLAYBACK) ? &dev->period_out_count[stream] : &dev->period_in_count[stream]; diff --git a/sound/usb/caiaq/device.c b/sound/usb/caiaq/device.c index 6d51770..515de1c 100644 --- a/sound/usb/caiaq/device.c +++ b/sound/usb/caiaq/device.c @@ -35,7 +35,7 @@ #include "input.h"
MODULE_AUTHOR("Daniel Mack daniel@caiaq.de"); -MODULE_DESCRIPTION("caiaq USB audio, version 1.3.13"); +MODULE_DESCRIPTION("caiaq USB audio, version 1.3.14"); MODULE_LICENSE("GPL"); MODULE_SUPPORTED_DEVICE("{{Native Instruments, RigKontrol2}," "{Native Instruments, RigKontrol3},"
At Mon, 27 Apr 2009 12:05:02 +0200, Daniel Mack wrote:
On Sun, Apr 26, 2009 at 01:18:52PM +0200, Takashi Iwai wrote:
The posting below didn't get any response yet, but the problem persists. Any hints, anyone?
The ALSA PCM core just relies upon two things from the lowlevel driver:
- The lowlevel driver calls snd_pcm_period_elapsed() at each time when the set-up period size has been processed by the hardware.
- The pointer callback reports the sane position as the current position; not below the previous position and not above the next period boundary.
Especially pulseaudio is very sensitive about these two things, because it always asks the driver the current position. Thus, if your driver doesn't fulfill the above conditions, it won't work properly.
Oh well. Stupid me. I think I fixed it, and wonder why it didn't break more things. Could you apply the patch below?
If you provide a proper changelog and your sign-off ;)
thanks,
Takashi
Thanks, Daniel
diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c index 3f45c0f..b13ce76 100644 --- a/sound/usb/caiaq/audio.c +++ b/sound/usb/caiaq/audio.c @@ -195,11 +195,14 @@ static int snd_usb_caiaq_pcm_prepare(struct snd_pcm_substream *substream)
debug("%s(%p)\n", __func__, substream);
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
dev->period_out_count[index] = BYTES_PER_SAMPLE + 1;
- else
- } else {
dev->period_in_count[index] = BYTES_PER_SAMPLE;
- }
- if (dev->streaming) return 0;
@@ -300,8 +303,7 @@ static void check_for_elapsed_periods(struct snd_usb_caiaqdev *dev, if (!sub) continue;
pb = frames_to_bytes(sub->runtime,sub->runtime->period_size);
pb = snd_pcm_lib_period_bytes(sub);diff --git a/sound/usb/caiaq/device.c b/sound/usb/caiaq/device.c index 6d51770..515de1c 100644 --- a/sound/usb/caiaq/device.c +++ b/sound/usb/caiaq/device.c @@ -35,7 +35,7 @@ #include "input.h"
MODULE_AUTHOR("Daniel Mack daniel@caiaq.de"); -MODULE_DESCRIPTION("caiaq USB audio, version 1.3.13"); +MODULE_DESCRIPTION("caiaq USB audio, version 1.3.14"); MODULE_LICENSE("GPL"); MODULE_SUPPORTED_DEVICE("{{Native Instruments, RigKontrol2}," "{Native Instruments, RigKontrol3},"
On Mon, Apr 27, 2009 at 12:12:14PM +0200, Takashi Iwai wrote:
The ALSA PCM core just relies upon two things from the lowlevel driver:
- The lowlevel driver calls snd_pcm_period_elapsed() at each time when the set-up period size has been processed by the hardware.
- The pointer callback reports the sane position as the current position; not below the previous position and not above the next period boundary.
Especially pulseaudio is very sensitive about these two things, because it always asks the driver the current position. Thus, if your driver doesn't fulfill the above conditions, it won't work properly.
Oh well. Stupid me. I think I fixed it, and wonder why it didn't break more things. Could you apply the patch below?
If you provide a proper changelog and your sign-off ;)
Oops :)
At Mon, 27 Apr 2009 12:18:05 +0200, Daniel Mack wrote:
On Mon, Apr 27, 2009 at 12:12:14PM +0200, Takashi Iwai wrote:
The ALSA PCM core just relies upon two things from the lowlevel driver:
- The lowlevel driver calls snd_pcm_period_elapsed() at each time when the set-up period size has been processed by the hardware.
- The pointer callback reports the sane position as the current position; not below the previous position and not above the next period boundary.
Especially pulseaudio is very sensitive about these two things, because it always asks the driver the current position. Thus, if your driver doesn't fulfill the above conditions, it won't work properly.
Oh well. Stupid me. I think I fixed it, and wonder why it didn't break more things. Could you apply the patch below?
If you provide a proper changelog and your sign-off ;)
Oops :)
From d50433f1047b85b150737c2f2588763ead2096ce Mon Sep 17 00:00:00 2001
From: Daniel Mack daniel@caiaq.de Date: Mon, 27 Apr 2009 12:14:23 +0200 Subject: [PATCH] ALSA: snd-usb-caiaq: fix reported elapsed periods
Reset the internal period position counter upon stream startup. This fixes initial aplay underruns and problems related to latency picky applications such as pulseaudio.
Bumped the version number to 1.3.14.
Signed-off-by: Daniel Mack daniel@caiaq.de
Thanks, applied now.
Takashi
On Mon, Apr 27, 2009 at 12:36:42PM +0200, Takashi Iwai wrote:
From d50433f1047b85b150737c2f2588763ead2096ce Mon Sep 17 00:00:00 2001
From: Daniel Mack daniel@caiaq.de Date: Mon, 27 Apr 2009 12:14:23 +0200 Subject: [PATCH] ALSA: snd-usb-caiaq: fix reported elapsed periods
Reset the internal period position counter upon stream startup. This fixes initial aplay underruns and problems related to latency picky applications such as pulseaudio.
Bumped the version number to 1.3.14.
Signed-off-by: Daniel Mack daniel@caiaq.de
Thanks, applied now.
Thanks :)
As this is a serious bugfix, it should make it into 2.6.30.
Daniel
At Mon, 27 Apr 2009 16:28:18 +0200, Daniel Mack wrote:
On Mon, Apr 27, 2009 at 12:36:42PM +0200, Takashi Iwai wrote:
From d50433f1047b85b150737c2f2588763ead2096ce Mon Sep 17 00:00:00 2001
From: Daniel Mack daniel@caiaq.de Date: Mon, 27 Apr 2009 12:14:23 +0200 Subject: [PATCH] ALSA: snd-usb-caiaq: fix reported elapsed periods
Reset the internal period position counter upon stream startup. This fixes initial aplay underruns and problems related to latency picky applications such as pulseaudio.
Bumped the version number to 1.3.14.
Signed-off-by: Daniel Mack daniel@caiaq.de
Thanks, applied now.
Thanks :)
As this is a serious bugfix, it should make it into 2.6.30.
Yep, I'll queue it up.
Takashi
participants (2)
-
Daniel Mack -
Takashi Iwai