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

[Lennart Poettering]

On Mon, 30.03.09 19:50, Daniel Mack (daniel at caiaq.de) wrote:

> Hi,
> 
> I'm currently trying to get PulseAudio to work with soundcards using the
> snd-usb-caiaq driver and have some strange effects I would like to
> share.
> 
> 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. As a matter of
> fact, once the stream is started by aplay, Rhythmbox can connect as well
> and submit data. If it can't (i.e., when the "Operation not permitted"
> message occurs), Rhythmbox will freeze completely.

To save power PA will close the audio device when idle for more than
2s. It will the reopen the device as soon as something is played
again. This closing/reopening is called suspend/resume in PA. In your
case the resume fails because ALSA returns EPERM. No clue why it does
that. Probably an ALSA issue. You'd need to single step through
pa_alsa_set_hw_params() to figure our which call exactly fails.

If PA cannot resume the device due to this error it just
won't. Unfortunately GST sinks are not supposed to stay
suspended. That results in RB freezing.

So the core of the problem is some ALSA or driver issue. PA tries to
configure the exact same hw params to the device that it configured
when it first initialized the device -- and that failed with EPERM for
an unkown reason.

> Another issue (that might - in contrast to the other one - be related to
> my driver) is the following message which pulseaudio happens to spit out
> regularily (most likely in bursts) after the stream start succeeded:
> 
> 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.
> 
> I'm not excluding a driver bug in general, but staring at my sources, I
> don't know where it could specifically misbehave. The only information my
> driver gives (and can give) is the current stream head, which the
> alogrithm does correctly, I'm very sure. But if it was a general issue,
> other sound cards would be equally affected.

No clue about this. All this tells you is that snd_pcm_avail()
returned some value < min_avail after POLLOUT was triggered. This
might be a driver problem or some problem elsewhere in ALSA. The
effect of this issue is that PA spins a loop being woken up by POLLOUT
without being able to write anything.

Lennart

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