Bug 455207

(In reply to comment #0)
> Description of problem:
> 
> The default.pa that's shipped with pulseaudio loads the suspend-on-idle module
> with a default timeout of 1s (AFAIK from reading the sources, I may have the
> units wrong).  This is too short.  It results in choppy audio performance for
> sound devices like USB audio or bluetooth audio that have significant wake-up
> times.  

Uh? Significant wakeup times? I am running this stuff on USB hw and everything
is fine.

> When the suspend-on-idle module is too aggressive like this, it shuts
> off the audio device in between normal desktop sound effects, and many of them
> are dropped because they are inherently short.

Hu? The devices are not suspended as long as there is still something playing. 

> * adjust the default timeout in the module, or in the system-supplied
> default.pa, to something more reasonable (300s or so)

Sorry, 300s is not reasonable. 5min is a long time.

> * don't enable this plugin at all (what's it's point, given that audio
> multiplexing is not an issue anymore?)

Power saving. Having the audio device open will cause frequent interrupts to be
triggered.

> * key the suspend operation to the X desktop idle interval, sort of like what
> pidgin does for its away/idle detection

Uh? Why? the audio device should be suspended when no stream is played. That's
the current behaviour. And sensible behaviour.

Please elaborate in which way your sound is choppy?

(In reply to comment #1)

> > It results in choppy audio performance for
> > sound devices like USB audio or bluetooth audio that have significant wake-up
> > times.  
> 
> Uh? Significant wakeup times? I am running this stuff on USB hw and everything
> is fine.

I have no way of measuring this for sure, but I would guess that my USB headset
has a wakeup time of around a tenth of a second.  My blueteooth headset has a
wakeup time of at least a quarter second.

On my desktop I have the 'ding' turned on when I switch virtual desktops; the
sound effect is short enough that it gets dropped occasionally on USB and
frequently on bluetooth.

> > When the suspend-on-idle module is too aggressive like this, it shuts
> > off the audio device in between normal desktop sound effects, and many of them
> > are dropped because they are inherently short.
> 
> Hu? The devices are not suspended as long as there is still something playing. 

As per my previous example -- desktop sound effects are implemented as short,
discrete sound samples, not as a continuous audio stream.  I agree that MP3's
are unaffected in the long run.

> > * adjust the default timeout in the module, or in the system-supplied
> > default.pa, to something more reasonable (300s or so)
> 
> Sorry, 300s is not reasonable. 5min is a long time.

I mention that because it's on the order of an X screen saver timeout.  Other
hardware devices on a system (screen, hard disk) do not power down as quickly.

> > * don't enable this plugin at all (what's it's point, given that audio
> > multiplexing is not an issue anymore?)
> 
> Power saving. Having the audio device open will cause frequent interrupts to be
> triggered.

If pulseaudio gets woken up every time I switch desktops (as per the example
above) than am not realizing any power savings.  I guess, technically, if it
wakes up the headset and doesn't play any sound, it may have save a little bit
of power, but that's a byzantine argument.

> > * key the suspend operation to the X desktop idle interval, sort of like what
> > pidgin does for its away/idle detection
> 
> Uh? Why? the audio device should be suspended when no stream is played. That's
> the current behaviour. And sensible behaviour.

By the same argument, the screen should go blank as soon as the mouse stops
moving...  but it would create a very jarring experience for the user.  I'm
arguing that suspending the audio needs to be balanced with realistic
observations of how fast an audio device can be woken up to play a sound.

> Please elaborate in which way your sound is choppy?

Sorry, my description was not very good.  The specific issue is that the
beginning of the sound is clipped.  For short audio samples this results in no
sound at all.

This really sounds like a bug in the way the BT device is accessed. The current way to access BT devices via ALSA is severely broken. We now have some patches which directly connect PA with BlueZ. When we finally merge them those issues should go away.

Anyway, increasing the suspend-on-idle timeout is the wrong solution to this. Fixing the BT acess is the right one.

hence closing this bug.

I just want to add here that this is an issue. When the sound effects are playing in gdm audio will blop before opening the stream and then blop when closing the stream. This is rather annoying.

Not correcting this makes the module unusable. Personally, I just comment it out. 

Proposed solutions:

1. Increase the timeout maybe a reasonable 10s (there had been an argument for this but it does not seem to work)
2. Reduce the sound level and the restore (fading gradually) before suspending.


I am using no bluetooth or other complicated sound setups. Just a normal laptop with a sound out to speakers. The problem is evident even using the built-in speakers.