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

[Richard Shaw]

On Tue, Dec 28, 2010 at 6:25 AM, Peter Hercek <phercek at gmail.com> wrote:
> 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?

One thing to try would be to rename your .pulse folder and relogin and
see if it still occurs. Probably not the problem but I reported a
crash last year when I tried to load the loopback module. It turns out
that since I had upgraded a couple of times (Fedora 8, 10, 12) that
some configuration cruft built up that the newer version of Pulse
didn't like.

Richard