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

[Lennart Poettering]

On Mon, 30.03.09 20:03, Daniel Mack (daniel at caiaq.de) wrote:

> 
> 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? ;)

Suspend/resume (as mentioned in my previous mail) is implemented by
closing/reopening the device. When we reopen we try to configure the
same hwparams as initially, and that fails with EPERM.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4