[pulseaudio-discuss] cannot control input devices from pavucontrol + crashes in recording tab

[Colin Guthrie]

'Twas brillig, and Peter Hercek at 28/12/10 12:25 did gyre and gimble:
> On 12/22/2010 07:58 PM, Peter Hercek wrote:
>> On 12/22/2010 05:45 PM, Colin Guthrie wrote:
>>> What most users end up doing is using module-loopback. It's records and
>>> then plays the input. This obviously shows up in pavucontrol as a
>>> regular stream and has fully (and independent) volume control and muting
>>> due to the fact that PA support per-stream volume control (at least on
>>> playback).
>> Yes, when I did this it was represented as "Line In" in the "Input
>> Devices" tab of pavucontrol. Works well. Well, except this quirk:
>>
>> I could use this but the problem is that when I do not have
>> pavucontrol or pavumeter (or some other application generating sounds
>> (e.g. like mplayer)) running then the module-loopback drops (the sound
>> from "Line In" stops). The sound resumes when I start pavucontrol or
>> some sound generating application (well I'm not sure whether all of
>> them work but mplayer restores the "Line In" sound). It is interesting
>> that pavumeter cannot restore the "Line In" sound; it reports
>> "Connection failed: Connection refused" instead.
>> This error state (when "Line In" is not monitored by the
>> module-loopback) seems to be there also after a reboot. Pulseaudio
>> daemon does not report any errors to messages log when it stops to
>> loop Line In to Output (log level was set to warning). Well,
>> pulseaudio reports "XX events suppressed" ocasionaly, but this never
>> seemed to matter (the sound was not choppy and did not seem
>> distorted). Typically, I have log level set to error to supress the
>> warning.
>>
>> Any idea what is wrong?
> 
> I looked at this better today and found out that the reason the loopback
> sound stops is that the pulseaudio servers exits. It thinks it is idle.
> It looks like when some sounds go over loopback (or pavumeter) it is not
> considered a usefull work (the message was: "core.c: We are idle,
> quitting..."). But when some sounds go from some other apllication (like
> e.g. xmms) or when pavucontrol is running then it is considered a
> usefull work and the server does not get idle. This looks like a bug to
> me. Streaming sounds over loopback is definitely usefull work for me.
> Should this be reported as a bug?
> Is there some workaround, some way to make pulseaudio server not to
> detect idling?

Hmm, this does indeed look like some kind of bug. I'll try and see if I
can reproduce here and work out what's wrong.

As a work around, you can possibly try commenting out
"module-suspend-on-idle" from default.pa.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]