[pulseaudio-discuss] "Operation not permitted" and "ALSA woke us up to write new data ..."

Daniel Mack daniel at caiaq.de
Mon Mar 30 11:03:47 PDT 2009

On Mon, Mar 30, 2009 at 07:50:51PM +0200, I wrote:
> First thing is random occurance of "Operation not permitted" messages
> from the pulseaudio daemon. I can - most of the time - connect using
> 'aplay -Dpulse', but Rhythmbox, for example, usually fails with this
> message:
> I: sink-input.c: Created input 1 "Playback Stream" on
>    alsa_output.plughw_0_0 with sample spec s16le 2ch 44100Hz and
>    channel map front-left,front-right
> I: protocol-native.c: Requested tlength=200.00 ms, minreq=10.00 ms
> I: protocol-native.c: Final latency 200.00 ms = 90.00 ms + 2*10.00 ms
>    + 90.00 ms
> I: module-alsa-sink.c: Trying resume...
> E: module-alsa-sink.c: Failed to set hardware parameters: Operation
>    not permitted
> I use the terms 'random' and 'usually' because I couldn't really find
> any pattern when that happens and what exactly it causes.

Ok, just some minutes after I wrote that it turned out that
suspend/resume calls seem to be the culprit. If I'm fast enough to start
a client right after the pulseaudio daemon came up, this doesn't happen.
But once the daemon decided to send the device to sleep it won't
recover. Is this a thing a driver has to implement? And is failing so
hard if a driver doen't do that intended? ;)


More information about the pulseaudio-discuss mailing list