device underruns

device underruns

[Daniel Mack]

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

Re: device underruns

[Daniel Mack]

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

Re: device underruns

[Takashi Iwai]

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
> 

Re: device underruns

[Daniel Mack]

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:
> 
> 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.

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},"

Re: device underruns

[Takashi Iwai]

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:
> > 
> > 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.
> 
> 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;
>  		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},"
> 

Re: device underruns

[Daniel Mack]

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:
> > > 
> > > 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.
> > 
> > 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>
---
 sound/usb/caiaq/audio.c  |   12 +++++++-----
 sound/usb/caiaq/device.c |    2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

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},"
-- 
1.6.2.1

Re: device underruns

[Takashi Iwai]

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:
> > > > 
> > > > 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.
> > > 
> > > 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

Re: device underruns

[Daniel Mack]

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

Re: device underruns

[Takashi Iwai]

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