PulseAudio мойка заикания

12

Я установил raspbian на свой Pi и настроил приемник PulseAudio с целью потоковой передачи всего звука с моего рабочего стола на Pi, приводя в действие динамики.

Я последовал этому хорошему описанию: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

Сначала это оказалось работать без проблем. Тем не менее, звук, посылаемый с рабочего стола, постоянно заикается на Pi, как если бы был постоянный переполнение буфера с отсутствием нескольких промежуточных сэмплов.

Я провел весь день, пытаясь найти причину, но безрезультатно. Базовая настройка:

  • проводная локальная сеть
  • последние raspbian pi (26 сентября 2013) с последними обновлениями прошивки
  • PulseAudio 2.0 с обеих сторон (рабочий стол Ubuntu)
  • Воспроизведение через mplayer, totem, ffplay
  • передача по сети через модуль-native-protocol-tcp

Вот что я попробовал:

  • Воспроизведение аудио прямо на Пи работает отлично.
  • Потоковая передача на другие (настольные) компьютеры работает нормально.
  • Отправка аудио по прямому соединению (с указанием $ PULSE_SERVER) работает довольно хорошо с очень небольшим заиканием, но все еще склонна к проблеме 2 (см. Ниже)
  • Отправка аудио через десктоп туннелирование PulseAudio обеспечивает постоянное заикание
  • Увеличение приоритетов / планирование в реальном времени ... не помогло
  • Фиксирование частоты дискретизации до 48 кГц ... не помогло
  • Установка алгоритма передискретизации на "тривиальный" ... не помогло
  • Настройка default-фрагментов / фрагмента-размера ... не помогла
  • Я не могу найти никаких признаков проблемы в журналах PulseAudio (показанных с момента, когда я начал воспроизведение):

    D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
    D: [alsa-sink] sink-input.c: Requesting rewind due to uncorking
    D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo is 0x0000, resuming
    I: [alsa-sink] alsa-sink.c: Trying resume...
    I: [alsa-sink] alsa-util.c: cannot disable ALSA period wakeups
    D: [alsa-sink] alsa-util.c: Maximum hw buffer size is 341 ms
    D: [alsa-sink] alsa-util.c: Set buffer size first (to 16384 samples),  period size second (to 16384 samples).
    I: [alsa-sink] alsa-util.c: ALSA period wakeups were not disabled
    D: [alsa-sink] alsa-sink.c: Latency set to 25.00ms
    D: [alsa-sink] alsa-sink.c: hwbuf_unused=60736
    D: [alsa-sink] alsa-sink.c: setting avail_min=15665
    I: [alsa-sink] alsa-sink.c: Time scheduling watermark is 15.00ms
    I: [alsa-sink] alsa-sink.c: Resumed successfully...
    I: [alsa-sink] alsa-sink.c: Starting playback.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo becomes busy.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] ratelimit.c: 115 events suppressed
    D: [alsa-sink] alsa-sink.c: Wakeup from ALSA!
    ... no more output, but stuttering continues ...
    

Проблема 2: как уже было сказано выше, я могу получить вполне нормальный звук с прямым подключением. Однако после нескольких пропусков в потоке (используя mplayer) сервер PulseAudio зависает и вообще не воспроизводит звук. Иногда его можно восстановить, перезапустив mplayer. Иногда он так сильно зависает, что PulseAudio нужно перезапустить. Иногда даже зависает, когда меняю только уровень громкости.

Согласно документам PulseAudio, преимущество прямого соединения по туннельному соединению заключается в улучшении управления буферизацией, что, по-видимому, указывает на то, почему я получаю хороший звук при прямом соединении: http://www.freedesktop.org/wiki/Software / PulseAudio / Документация / Пользователь / Сеть /

У меня сейчас нет идей. Что может вызвать заикание и проблему 2? Просто идея, как продолжить отладку также будет оценена.

farindk
источник
Как вы проигрывали аудио напрямую? У меня не было проблем с aplay, но paplay заикается и ужасно эхом.
Джон Ла Рой
Я использовал mplayer, totem, madplay ... Но тот факт, что разные игроки ведут себя по-разному, подтверждает моё предположение, что это похоже на программную проблему с буферизацией данных. Некоторые игроки опережают в реальном времени больше данных, чем другие.
farindk
У меня проблемы с игрой синусоидальных волн . Я думаю, что мне нужно решить это, прежде чем я смогу попробовать потоковую передачу по локальной сети.
Джон Ла Рой

Ответы:

6

tsched_buffer_sizeи tsched_buffer_watermarkбыли настройки, которые заставили это работать для меня.

Я запускаю свой PulseAudio как системный экземпляр, поэтому конфигурация находится в /etc/pulse/system.pa. Если вы используете вместо этого экземпляр сеанса, то конфигурация будет в /etc/pulse/default.pa.

Это по умолчанию:

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
load-module module-detect
.endif

Я заменил это следующим: (то есть закомментировал)

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
#load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
#load-module module-detect
.endif

Затем я добавил следующую строку:

load-module module-alsa-card device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144

См. Http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index6h3.

Фил
источник
Хорошая точка зрения. Я пытался, но это не помогло. Даже с гораздо большими размерами буфера. Отправка аудио по прямому соединению путем установки PULSE_SERVER на Pi дает чистый звук, но простое изменение громкости в конечном итоге заморозит соединение. Звук через туннелирование все равно дает заикание. Я предполагаю, что это действительно проблема PulseAudio, потому что при таких больших размерах буфера (я использовал 4 МБ), нужно видеть, что аудио декодируется заранее в начале файла. Но это не так. Так что должно быть что-то замедляющее пополнение.
farindk
Встречаясь с такими же проблемами. В моем конкретном случае PULSE_SERVER + mplayer работает как шарм, в то время как PULSE_SERVER + clementine (который, я считаю, использует gstreamer) заикается ужасно. Есть идеи, чем они отличаются?
Джонатан Проценко
@Protzenko: Я полагаю, что не глядя ни на какой источник, mplayer может отправлять данные до тех пор, пока PulseAudio не блокирует, а gstreamer может отправлять данные, синхронизированные по ссылке в реальном времени. Это будет означать, что в первом случае буферы гораздо более заполнены, и, следовательно, существует большая задержка.
farindk
Я вижу ту же проблему: PULSE_SERVER + ffmpeg в порядке, PULSE_SERVER + mpd жалюзи и неявные
опустошения
3

Суть в том, что вы должны использовать module-tunnel-sink-new, но вы также должны сделать несколько других изменений, чтобы получить беспрепятственный сетевой звук на Raspberry Pi 1.

  1. Запустите pulseaudio на Raspberry Pi с приоритетом в реальном времени:
pulseaudio --start --high-priority=yes --realtime=yes

Позвольте нам использовать термин отправитель для обозначения компьютера, который отправляет поток на ваш Raspberry Pi.

  1. Установите default-fragmentsи default-fragment-size-msecв daemon.confat sender эти значения:
default-fragments = 8
default-fragment-size-msec = 12
  1. Используйте module-tunnel-sink-newэту команду, отправив команду sender (если имя хоста вашего raspberry pi - RP1, и у вас есть mDNS, работающий в вашей локальной сети. В противном случае просто используйте IP-адрес вашего raspberry pi).
pactl load-module module-tunnel-sink-new server=RP1.local

С этими настройками я получаю звук без заикания от raspberrypi 1 по беспроводной сети, работающей на скорости 54 Мбит / с (в моей настройке отправитель использует ethernet, а RP1 использует wlan). На самом деле, это работает, даже когда отправитель и raspberrypi используют wlan, по крайней мере, если в беспроводной сети нет других устройств.

Ханс Экбранд
источник
Прекрасно работает до сих пор. Я обнаружил, что для моего Pi3 (с несколько более новым Debian / программным обеспечением) мне пришлось изменить что-то еще для настройки «фрагментов по умолчанию». (а именно, что-то настройки tsched=0, см. wiki.archlinux.org/index.php/PulseAudio/… )
rien333
Если вы все еще испытываете заикание, вики-сайт arch также рекомендует перейти на протокол потоковой передачи rtp: wiki.archlinux.org/index.php/PulseAudio/…
rien333
1

Вы проверили эту страницу:

http://manpages.ubuntu.com/manpages/lucid/man5/pulse-daemon.conf.5.html

УСТАНОВКИ ФРАГМЕНТА ПО УМОЛЧАНИЮ

   Some hardware drivers  require  the  hardware  playback  buffer  to  be
   subdivided  into  several  fragments.  It  is  possible to change these
   buffer metrics for machines with high  scheduling  latencies.  Not  all
   possible  values  that  may  be  configured  here  are available in all
   hardware. The driver will to find the nearest setting supported. Modern
   drivers that support timer-based scheduling ignore these options.

   default-fragments= The default number of fragments. Defaults to 4.

   default-fragment-size-msec=The  duration of a single fragment. Defaults
   to 25ms (i.e. the total buffer is thus 100ms long).
Альтер Шведе
источник
Да, пробовал, но это не помогло. Как я уже говорил, воспроизведение звука на самом устройстве работает нормально. Я предполагаю, что это проблема сетевого протокола с туннелированием PulseAudio. Даже протокол прямого соединения работает хорошо. Теперь я переключился на простое потоковое оборудование Bluetooth, которое является надежным и использует RPi для других целей.
farindk
1

Чтобы избавиться от проблем с заиканием или тайм-аутом, попробуйте понизить FW:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12
user13034
источник
1
ВНИМАНИЕ! Будьте осведомлены о том, что такое rpi-updateиспользование может сделать для вашей системы.
earthmeLon
@earthmeLon Вы можете хотя бы дать ссылку или попытаться сообщить нам, что такое использование rpi-updateможет сделать для наших систем ...
user11171
Обязательно прочтите Руководство и проведите некоторые исследования, чтобы понять, как это влияет на вашу систему и возможные угрозы.
earthmeLon
0

Я понял, что эта проблема может быть связана с версией ядра. После обновления с 3.6.11 до 3.12.0 я постоянно получал эти потери. Переход на 3.6.11 решил проблему для меня.

Мануэль Фо
источник
0

Я читал эту страницу пару раз ... Я также был разочарован заиканием комбинации RaspberryPi-pulseaudio-network. Я искал немного больше и нашел страницу, где я нашел часть решения:

=> Отключить module-suspend-on-idle в файле default.pa (или system.pa).

Вот, заикание исчезло!

Теперь единственная проблема в том, что через некоторое время (от 10 до 20 секунд) воспроизведение зависает: - /

Какие-либо предложения?

Йорн Кристенсен
источник