Capture stops after a while

[DuratarskeyK]

I have this weird problem with skype, after some time in a conversation microphone just stops working. It could be anything from 30 minutes to 2 hours. I don't know what other information I need to provide at the moment.

[i-rinat]

The bug is weird indeed. I expected it to either work or not to work at all. But not to stop in the middle.

In the issue #26 microphone doesn't work at all. But instrumentations showed that recording works, data are passed to Skype, but for some unknown reason Skype treats that as silence. Which together with this issue makes me assume that Skype could be doing some noise calibration routine. And cutting levels.

Apulse at the moment have no implementation of volume-related API part. Could you compile debug version of apulse and collect output? It's worth to check whenever there are irregularities in function patters when that microphone dysfunction starts. Debug version of apulse (configure with cmake -DCMAKE_BUILD_TYPE=Debug ..) emits a lot of text to standard output. It's worth to redirect it to a file.

[i-rinat]

There are also reports on the Internet about microphone stopped working in the middle a Skype call.

[mtbc]

While I haven't run into this bug, it may be relevant that I also disable the option for Skype being able to adjust the gain by itself during the call.

[i-rinat]

Allowing Skype to adjust volume causes it to call pa_context_set_source_volume_by_index a lot.

Can't figure out why it calls it so much. And it sets volume to 2 (of 65536 max), which is almost muted. And volume never gets higher. So in experimental implementation Skype just effectively mutes Capture element, which results in no sound at all.

I've also seen couple of times when Skype just stops calling anything volume-related. Looks like after a certain number of tries it gives up and stops accepting data from microphone.

[roydenyates]

Yeah, I get this too, using skype and apulse 0.1.6 on an old laptop (Intel Pentium M 1.86GHz, don't laugh!) running Lubuntu 16.04. I gave up on pulseaudio on this device due to horrible, uncorrectable jitter. Apulse works well - until the sound from my side disappears. Disabling Skype control of mike volume is no solution for me. Still happens. Unlike the OP, it often is 3 to 5 mins into a call. Next 3/4/5 calls of 5-7 minutes are fine....

[h1z1]

Does the audio gradually become delayed / out of sync? In your case it could be just the buffer (buffer_period and buffer_size in asoundrc). I've had it happen more on a laptop after powersave kicked in or over a laggy vpn (packetloss outside, inside just looked like jitter since they weren't lost).

FWIW Microsoft really doesn't like the Linux client.

[roydenyates]

No, my side is perfect until it just disappears from the Skype call - in conversation it quickly becomes apparent, as I hear the other party's "hello, hello can you hear me" just fine.

This does seem apulse related, as when I had Skype working with pulseaudio on this laptop, I never experienced this kind of drop-out. And I don't either on a more powerful desktop with Skype and pulseaudio.

[i-rinat]

In another similar issue, we tried to dump to a file actual information, that is passed to Skype from apulse: #26 (comment). Those are raw data, single channel, 48000 Hz, S16. Interestingly enough, there is sound. So Skype was getting the data. But apparently, ignored it.

Apulse is not a full implementation of PulseAudio API. There is a volume control part, which is not implemented, but is probed by Skype. I tried to implement it in a straight way, but then Skype sets volume to 2 (of about 65536, I think. Actual number is big, but I don't remember exact value).

I'd like to know what's wrong, but I couldn't figure that out.

[i-rinat]

I recently changed (computer) machine I'm using daily, and found similar issue, but with Firefox. Playback was fine, but capture stopped after a couple of seconds.

It turned out, that there are two bugs that caused that. First, there were no enough periods in buffer. Application asked for the right sizes, but ALSA driver increased period size, while buffer size was kept the same. Numbers were: asked ~300 frames for period and 1200 for buffer, got 940 frames in period, 1200 in buffer. And second, there were no appropriate state recovery. Actually, snd_pcm_recover() from alsa-lib ( which I'm already calling) should handle it, but it for some reason does not. So I just added a workaround code.

Related changes: ec575ce...86f0841.

[DoricRedPanda]

I bumped into the issue with discord. Capture stopped working after 30-50 seconds. I changed my asoundrc to use dsnoop as capture.pcm.

[ghost]

I also have the same issue as @DoricRedPanda