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
