c++ - 奇怪的 PulseAudio 监控设备行为

Question

面对奇怪的 PulseAudio 监控设备(即播放发送到扬声器的声音的音频输入设备)行为。我已根据 PulseAudio 文档 https://freedesktop.org/software/pulseaudio/doxygen/parec-simple_8c-example.html 中的代码将真实项目中的代码简化为简单示例，我只添加了时间限制和读取字节数。例如，它工作 30 秒并打印读取的字节数。问题是如果在程序运行期间播放某些内容，字节数会有很大差异。我已经执行了这个程序并并行执行了 bash for 循环，该循环由 aplay 和短 tada.wav 文件组成。差异为 9%。为了对其进行更多测试，我尝试与 PulseAudio 示例并行运行 4 个这样的循环，差异甚至更大 - 34%。但是如果我用长 mp3 文件运行 mplayer 而不是几个短 wav 的 aplay - 没有这样的区别，字节数类似于没有播放声音的情况。

这种行为导致我的真实项目中的声音处理代码失败，所以如果有人可以建议如何解决它 - 我将非常感激。

Windows 上的类似代码，基于 Qt 并使用立体声混音器设备作为 PulseAudio 监视器的模拟工作没有此类问题。

这是我基于 PulseAudio 文档示例的代码:

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <iostream>
#include <chrono>

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>

#include <pulse/simple.h>
#include <pulse/error.h>

#define BUFSIZE 1024

using namespace std;
using namespace std::chrono;

int main(int argc, char *argv[])
{
    int duration = 30000;
    int64_t readBytesCounter = 0;
    milliseconds msStart = duration_cast< milliseconds >(system_clock::now().time_since_epoch());

    /* The sample type to use */
    static const pa_sample_spec ss = {
        .format = PA_SAMPLE_S16LE,
        .rate = 44100,
        .channels = 2
    };
    pa_simple *s = NULL;
    int ret = 1;
    int error;
    /* Create the recording stream */
    if (!(s = pa_simple_new(NULL, argv[0], PA_STREAM_RECORD, "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor", "record", &ss, NULL, NULL, &error))) {
        fprintf(stderr, __FILE__": pa_simple_new() failed: %s\n", pa_strerror(error));
        goto finish;
    }
    for (;;) {
        uint8_t buf[BUFSIZE];
        /* Record some data ... */
        if (pa_simple_read(s, buf, sizeof(buf), &error) < 0) {
            fprintf(stderr, __FILE__": pa_simple_read() failed: %s\n", pa_strerror(error));
            goto finish;
        }
        readBytesCounter += BUFSIZE;

        milliseconds msCurrent = duration_cast< milliseconds >(system_clock::now().time_since_epoch());
        int elapsed = msCurrent.count() - msStart.count();
        if (elapsed > duration)
        {
            cerr << int(elapsed / 1000) << " seconds elapsed, terminating" << endl;
            cerr << readBytesCounter << " bytes read" << endl;
            goto finish;
        }
    }
    ret = 0;
finish:
    if (s)
        pa_simple_free(s);
    return ret;
}

可以使用以下命令构建:

g++ -o main main.cpp -lpulse -lpulse-simple -std=c++11

我从 http://d0.waper.ru/f/462151/23/HgDwimvX37CwxWqW38eywg%2C1485353628/7d74/9/462151.wav/tada.wav 中获取的示例 wav 文件

测试结果如下:

测试一、喇叭没有声音

$ time ./main
30 seconds elapsed, terminating
5323776 bytes read

real    0m30.028s
user    0m0.168s
sys     0m0.388s

测试 2. Bash for 循环“for i in seq 1 22; do aplay tada.wav; done”，背景是短 wav 文件。字节数增加了 5798912/5323776 = 1.089 倍。

$ time ./main 
30 seconds elapsed, terminating
5798912 bytes read

real    0m30.023s
user    0m0.120s
sys     0m0.184s

测试 3. 4 Bash for 循环，后台有短 wav 文件。字节数增加了 7129088/5323776 = 1.339 倍。

$ time ./main 
30 seconds elapsed, terminating
7129088 bytes read

real    0m30.019s
user    0m0.164s
sys     0m0.196s

测试 4. mplayer 背景为长 mp3。 5288960/5323776 = 0.993，即没有明显的字节数差异。

$ time ./main 
30 seconds elapsed, terminating
5288960 bytes read

real    0m30.024s
user    0m0.096s
sys     0m0.204s

尝试执行一组每个测试，平均字节数 - 相似的差异。

P.S.:我的系统配置:

• 操作系统 Ubuntu 16.04.1 amd64
• pulseaudio 1:8.0-0ubuntu3.2
• alsa-base 1.0.25+dfsg-0ubuntu5

Answer 1

这是 PulseAudio 邮件列表中 Tanu Kaskinen 的回复 https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027412.html .不是完整的答案，而是一些解释和解决方法:

You're probably hitting a known bug we have with rewind handling in monitor sources ("known" means in this case that the symptoms are known, but not the exact cause). When a stream starts to play to the monitored sink, the sink will rewrite its playback buffer contents (this is called "rewinding"), and this causes a glitch in the monitor source (some extra audio apparently gets pushed to the recording stream, judging from your experiments). I hope to fix this some day, but it doesn't look like I'll have time for it in the near future. If you have the time and motivation to investigate and fix the bug, that would be awesome.

As a workaround, you can probably reduce the magnitude of the error by reducing the playback buffer size. To do that, pass tsched_buffer_size=X to module-udev-detect in /etc/pulse/default.pa (replace X with the buffer size in bytes)."