У меня аналогичная проблема с Pulseaudio 6.0. Pulseaudio имеет тенденцию либо не воспроизводиться вообще, либо зависать через несколько минут воспроизведения. Также использую Arch Linux. Пробовали как пользовательский режим (запуск от имени root), так и системный режим, так как у меня Pi настроен без головы.

Ниже приводится сообщение об ошибке, которое Pulseaudio выводит всякий раз, когда он зависает (обычно через минуту или две воспроизведения).

E: [alsa -ink-bcm2835 ALSA] alsa -ink.c: ALSA разбудила нас, чтобы записать новые данные на устройство, но на самом деле писать было нечего!
E: [alsa-сток-bcm2835 ALSA] alsa-сток.c: Скорее всего, это ошибка в драйвере ALSA '(null)'. Сообщите об этой проблеме разработчикам ALSA.
E: [alsa -ink-bcm2835 ALSA] alsa -ink.c: Мы проснулись с установленным POLLOUT, однако последующая snd_pcm_avail () вернула 0 или другое значение <min_avail.

У меня тоже ужасные проблемы с bcm2835 и Pulse 6.
Если я запускаю pulseaudio и запускаю paplay локально (на пи), он сразу же начинает воспроизведение с искаженным звуком. Некоторые части PCM звучат так, как будто они воспроизводятся не по порядку. Чем дольше воспроизводится звук, тем хуже становится, пока звук не становится почти чистым шумом.
Убийство (CTRL + C) и последующий запуск paplay вызывают повторяющуюся картину искажения звука или чистой тишины, пока на 8-м прогоне звук не воспроизводится идеально. Сыграйте снова, и цикл начнется заново.
Шаблон искаженный, безмолвный, искаженный, искаженный, безмолвный, искаженный, беззвучный, идеальный.
Если я использую USB-гарнитуру, paplay работает каждый раз.
У меня было это, когда у меня идеально воспроизводится звук через USB-гарнитуру, а затем я отключаю USB-ключ, и звук правильно воспроизводится через аналоговый порт пи. Остановите и перезапустите звук, и он будет искажен.

Моя настройка: pulseaudio + mpd + ncmpcpp.

Моя тестовая установка - запускать песню и многократно воспроизводить / приостанавливать воспроизведение. После максимум 3-х раз воспроизведения / паузы pulseaudio будет зависать, и ее необходимо перезапустить.
Это происходит только на моем Raspberry B + с чипом bcm2835, как с дистрибутивами на основе Debian, так и с Arch. У меня нет проблем с точно такой же настройкой на моем настольном ПК со звуковым чипом Intel. Проблем не было с ядром 3.6 (но я не хочу использовать древний дистрибутив).

Ни одно из обходных решений, которые можно найти в Интернете (tsched = 0, отключение модуля-приостановки-при-простое, ...), не помогло. Я наконец откажусь от этой проблемы, потому что я не находил решения уже больше года. Либо я куплю себе Raspberry 2, либо буду использовать mpd с бэкэндом ALSA, потому что это отлично работает.

@maxnet , эта проблема решена? Если да, закройте этот вопрос.

Я так не думаю. Он также не работает с Raspberry 3 (что неудивительно, потому что он использует тот же чип / драйвер: snd_bcm2835).

У меня эта проблема на моем Raspberry 3, работающем под управлением ubuntu 16.04. В качестве обходного пути я добавлю в свою программу 5-секундную задержку тайм-аута, но это нарушит естественность вывода (это синтезатор речи)

Та же проблема с моими pi3 и ubuntu mate 16.04 и mpd звучит фантастически, если я не изменяю громкость (что вызывает заикание или потерю звука), также теряет звук случайным образом среди других проблем. Действительно разочаровывает.

Та же проблема в Rpi B (не 2 или 3) с последним ядром (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Можно подтвердить эту проблему с rpi3, на котором запущена Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux на raspbian .. Pulseaudio обычно прекращает воспроизведение между треками, которые я скармливаю ему из mpd (с другого хоста по сети). При попытке воспроизвести 24-битный звук flac через mpd для импульсного воспроизведения он воспроизводит только 2 секунды и зависает.

Подтверждение проблемы при запуске rpi3 4.9.30-v7+ . Заполнение списка воспроизведения mpds и начало воспроизведения обычно работают до завершения списка воспроизведения, но ручное изменение треков, остановка и перезапуск остановят работу аудиовыхода, пока я не перезапущу mpd.

audio_output {
        type            "alsa"
        name            "ALSA Output"
#       device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
#       auto_resample   "no"
#       auto_channels   "no"
#       auto_format     "no"
}

Имея такое же проблемное поведение, как описано @flittermice : разочарован:
Система представляет собой RPi2, на которой запущена свежая установка Raspbian Stretch (9.1) с pulseaudio v10.0-1 + deb9u1, ядро ​​4.9.59+
Читал связанные статьи / руководства / потоки, но воспроизведение MPD зависает, как описано выше, пока я не отключу и не перезапущу pulseaudio.

Кто-нибудь еще нашел решение этого? : cross_fingers:: smile:

Нашел что-то интересное (возможно):
Когда pulseaudio зависает (как описано выше), дважды (!) Выполнение команды "paplay" возобновляет воспроизведение звука:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• В первый раз время ожидания команды paplay истекает (или ее можно прервать с помощью Ctrl + C)
• Второй раз работает команда paplay, и теперь звук из MPD возобновляется.

Работает случайное количество времени, затем возвращается к поведению @flittermice : sob:

Я продолжил отладку в этой проблеме и обнаружил, что использование Pulseaudio эзотерической функции ALSA, называемой «перемотка», вызывает эту проблему.
К сожалению, нет возможности конфигурации, чтобы остановить PA от использования этой функции.
Эта ветка постоянно отключает его в исходном коде: https://github.com/strfry/pulseaudio/tree/no_rewind
Если вы можете собрать и установить его в своей системе, проверьте, решает ли это вашу проблему.

Я продолжил отладку этой проблемы и обнаружил, что использование Pulseaudio эзотерической функции ALSA
так называемая «перемотка» вызывает эту проблему.
К сожалению, нет возможности конфигурации, чтобы остановить PA от использования этой функции.

Но сможет ли Pulse правильно работать, если убрать эту функцию?

Имейте в виду, что часть функций, которые он предлагает в качестве звукового сервера, заключается в смешивании звука, который может исходить из нескольких приложений вместе.
И я могу представить, что если вы хотите, чтобы новые приложения могли мгновенно добавлять звуки в микс, вам действительно нужен способ отбросить часть существующего буфера.
В противном случае вы можете добавить новый звук только в конец буфера, и это приведет к задержке, которую приложение может не ожидать. И что может быть проблемой для некоторых целей (например, видео со звуком)

@maxnet Правильное исправление (у меня нет)
Он отлично работает для моего приложения с низкой задержкой, для воспроизведения музыки с помощью MPD может быть немного неприятно, если не будет перемотки (без исправления PA только для буферов с низкой задержкой).

Всегда низкая задержка подразумевает использование крошечных буферов.
Что мне тоже не идеально.

Могу поспорить, что правильное исправление будет в модуле ядра ...

@strfry : отношение к перемотке ALSA звучит разумно. Когда pulseaudio становится "недовольным", обычно это заканчивается этой строкой:

D: [alsa -ink-bcm2835 ALSA] source.c: Обработка перемотки назад ...

Однако я в некоторой степени согласен с @maxnet , и, вероятно, есть причина, по которой ALSA делает это в первую очередь ...: wink:

Это не работает только на Raspberry Pi или общая проблема pulseaudio + ALSA?
Поскольку проблема все еще существует уже более трех лет, должны ли мы сообщать об этом разработчикам pulseaudio / ALSA, а не здесь?

@ pjotrek-b Не работает только со встроенной звуковой «картой» Raspberry PI. Мы успешно используем pulseaudio в качестве сетевого звукового сервера со звуковой картой USB в течение нескольких месяцев без проблем.

Я могу подтвердить заявление @jekhor .
Та же самая конфигурация отлично работает с моей звуковой картой USB (snd_usb_audio) на Raspberry Pi.

Как говорится в файле журнала: «E: [alsa -ink-bcm2835 ALSA] alsa -ink.c: Скорее всего, это ошибка в драйвере ALSA '(null)». Сообщите об этой проблеме разработчикам ALSA. ». Кто-нибудь знает как это сделать?

@jekhor : Спасибо, что прояснили это! :улыбка:

Что сейчас озадачивает, я всегда думал, что это так:
application > pulseaudio > ALSA > driver > hardware

Если да, то как могут безупречно работать те же приложения , в которых есть эта проблема, при прямом использовании ALSA?
application > ALSA > driver > hardware

Теперь, если эта проблема характерна для встроенной звуковой карты / чипа RPi, почему эти проблемы не возникают и при использовании только alsa? :смущенный:

@strfry : Я нашел довольно подробную статью о "Перемотке назад" в документации pulseaudio .

Я читал его отрывки, и теперь он мне больше не кажется «эзотерическим». Поскольку вы посмотрели на его код: есть идеи, что могло заставить pulseaudio "застревать"?
Как я уже упоминал выше, двойное выполнение "paplay", кажется, дает ему "толчок", чтобы он снова вернулся к работе ...: smile:

@ pjotrek-b Конечно, это имеет смысл, учитывая цели дизайна Pulseaudio. Это «эзотерично» в том смысле, что 99% обычных приложений ALSA никогда не используют перемотку назад и, таким образом, запускают менее проверенный путь в драйвере ALSA. К сожалению, Pulseaudio не имеет возможности отключить использование этой потенциально ошибочной функции (как и другие, например, планирование на основе таймера).
Я не отлаживал точные детали, но в основном Pulseaudio застревает в бесконечном цикле, потому что ALSA не может правильно сообщить, когда пришло время снова записать аудиоданные на устройство.
Несмотря на возможности решения этой проблемы на стороне Pulseaudio, это ошибка драйвера ALSA.
Я подозреваю, что выпуск новых потоков будет генерировать события, которые Pulseaudio ждет, когда он застревает.

@flittermice Я полагаю, что в этом случае ответственный разработчик ALSA - это кто-то из разработчиков ядра Raspberry Pi, написавший драйвер snd_bcm2835, поэтому этот репозиторий будет правильным местом, чтобы сообщить об этом.

Простой пример кода, демонстрирующий явно неправильное поведение ALSA при использовании перемотки, вероятно, будет полезен разработчикам ядра при внимательном рассмотрении этой ошибки.

@ pjotrek-b Конечно, это имеет смысл, учитывая цели дизайна Pulseaudio. Это «эзотерично» в том смысле, что 99% обычных приложений ALSA никогда не используют перемотку назад и, таким образом, запускают менее проверенный путь в драйвере ALSA. К сожалению, Pulseaudio не имеет возможности отключить использование этой потенциально ошибочной функции (как и другие, например, планирование на основе таймера).
Я не отлаживал точные детали, но в основном Pulseaudio застревает в бесконечном цикле, потому что ALSA не может правильно сообщить, когда пришло время снова записать аудиоданные на устройство.
Несмотря на возможности решения этой проблемы на стороне Pulseaudio, это ошибка драйвера ALSA.
Я подозреваю, что выпуск новых потоков будет генерировать события, которые Pulseaudio ждет, когда он застревает.

@flittermice Я полагаю, что в этом случае ответственный разработчик ALSA - это кто-то из разработчиков ядра Raspberry Pi, написавший драйвер snd_bcm2835, поэтому этот репозиторий будет правильным местом, чтобы сообщить об этом.

Простой пример кода, демонстрирующий явно неправильное поведение ALSA при использовании перемотки, вероятно, будет полезен разработчикам ядра при внимательном рассмотрении этой ошибки.

Если да, то как могут безупречно работать те же приложения, в которых есть эта проблема, при прямом использовании ALSA?

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

Используется в ситуациях, когда происходит изменение планов.
Если Pulse уже отправил звук в течение следующих 2 секунд на устройство, и внезапно подключается другой клиент Pulse и также хочет воспроизвести звук - без необходимости ждать, пока эти 2 секунды закончатся первыми, - он должен сообщить звук устройство, чтобы отбросить предыдущий буфер и заменить его новыми данными, в которые добавлен дополнительный звук.

Конечно, если вы используете крошечные буферы, которые хранят миллисекунды вместо секунд звука, можно обойтись без перемотки.
Однако я не думаю, что это предпочтительнее.
В Linux нет никаких гарантий относительно количества процессорного времени, которое получает какое-либо приложение, или о том, что оно делится поровну, это не операционная система реального времени.
Если другое приложение использует много, а Pulse не успевает постоянно держать этот крошечный буфер заполненным, он будет опустошаться, и ваш звук будет прерывистым.

Как я уже упоминал выше, двойное выполнение "paplay", кажется, дает ему "толчок", чтобы он снова вернулся к работе ...: smile:

Pulse Audio также закрывает соединение со звуковым устройством через 5 секунд после отключения последнего использовавшего его клиента, если в это время другие клиенты не подключаются.
И снова откроет его в следующий раз, когда клиент захочет его использовать.
Поэтому, если между вашими командами достаточно времени, это также может быть причиной, по которой он снова работает.

@strfry и @maxnet :
Большое спасибо за подробные ответы!

Кто-нибудь знает, остается ли это проблемой в последней версии Raspbian (с ядром 4.14.y)?

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

Я бы проверил, но сейчас у меня нет времени тестировать ...: разочаровано:
На всякий случай: могу ли я снова открыть его, если я протестирую его через 30 дней, а проблема все еще существует?

Хотя я почти уверен, что никаких улучшений не было, я не могу внести большой вклад в эту конкретную ошибку. Я купил внешнюю звуковую карту USB с чипсетом PCM2704 и теперь доволен драйвером snd_usb_audio.
Использование выхода HDMI на распи было бы хорошим вариантом, но мой распи даже отказывался загружаться с кабелем HDMI, подключенным к AV-ресиверу ... но это уже другая история.

Закрытие из-за отсутствия активности. Отправьте запрос на повторное открытие, если вы считаете, что эта проблема по-прежнему актуальна.

Могу подтвердить, что это происходит с моим Rasp Pi 3
Я запускаю ArchARM с версией ядра 4.14.69

Могу подтвердить, что это все еще происходит на моем RPI3:

Linux 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux

Пытаясь использовать mpd с pulseaudio, я получаю:

Nov 05 09:25:17 noise systemd[1]: Started Music Player Daemon.
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

Есть ли шанс снова открыть эту проблему?

Могу подтвердить, что это происходит с моим Rasp Pi 3
Я запускаю ArchARM с версией ядра 4.14.69
Это было из-за неправильного разрешения, у меня это сработало.

@ l4rzy : ты заставляешь нас любопытствовать. Какие разрешения?

@flittermice : Ой, я неправильно понял ситуацию, так как я комментировал это несколько месяцев. Дело не в разрешениях.
Я попытался настроить свой Raspberry Pi 3 для аудиосервера Pulse в локальной сети, он работал без проблем, но через некоторое время ничего не воспроизводил, аудиосервер Pulse автоматически отключился. Позже я установил mpd для воспроизведения музыки из SoundCloud, который всегда открывает соединение с Pulse и поддерживает его работу. Думаю, неплохой обходной путь.

@ l4rzy : Работать - это

Кстати: Вы когда-нибудь пробовали не загружать "module-suspend-on-idle" в default.pa?

модуль нагрузки модуль приостановить на холостом ходу

@flittermice я пробовал. Не помогает.

Pulseaudio по-прежнему не работает с snd_bcm2835. Не могли бы вы снова открыть этот выпуск?

Я также могу подтвердить, что это не работает для меня. Я тестировал другой код и параметры компиляции, и мне не удалось заставить его работать. Я использую ArchLinux ARM и все новейшее программное обеспечение. Я рад помочь отладить, если возможно.

Для меня, насколько я могу судить, проблема связана с размером буфера, о котором сообщает модуль bcm2835_alsa. Аудиобуфер, сообщаемый для импульса, составляет 8816 бит, что достаточно для приблизительно 1,56 мс звука из сетевого потока. Я недостаточно разбираюсь в оборудовании, чтобы найти спецификации, но здесь что-то не так. Согласно самому ALSA (то есть не импульсному модулю) размер буфера намного больше логических 131072 бит. Если бы я догадывался, Pulse думает, что не может сохранить буфер заполненным для карты, и пытается перемотать назад, потому что ему говорят, что есть программный предел в 8816 бит ... но, может быть, я здесь далеко не так.

Была такая же проблема (это действительно раздражает), @ JamesH65 не могли бы вы снова открыть ее, чтобы отслеживать ее?

Хммм ... Я не могу воспроизвести это с Raspberry Pi 3 B v1.2 и последним ядром 4.19.34 (обновлено rpi-update на https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). Понятия не имею, почему драйвер не изменился с 2016 года. Может быть, какие-то изменения прошивки ВК?

Привет, на Raspberry Pi 4 B v1.1 ядро ​​5.3.0-1014 имеет ту же проблему с затуханием звука с pulseaudio v13.0. Звук пропадает, если в pavucontrol выбран стереовыход. Есть ли решение?

@acegallagher :

Аудиобуфер, сообщаемый для импульса, составляет 8816 бит, что достаточно для приблизительно 1,56 мс звука из сетевого потока.

Я думаю, это связано с тем, что PulseAudio по умолчанию определяет приемники как Mono ( из-за этой проблемы ), а размер буфера по умолчанию для них меньше.
Попробуйте обновить конфигурационный файл профиля PA по умолчанию, чтобы вместо этого создавались стерео приемники, так как это заставит PA создавать приемники с device.buffering.buffer_size = "17632" , что кажется лучше!

@ olevenets2

Привет, на Raspberry Pi 4 B v1.1 ядро ​​5.3.0-1014 имеет ту же проблему с затуханием звука с pulseaudio v13.0. Звук пропадает, если в pavucontrol выбран стереовыход. Есть ли решение?

Обязательно обновите конфигурационный файл профиля PA по умолчанию, чтобы стереовыход действительно работал с PA на RPI 4, и убедитесь, что у вас есть load-module module-udev-detect а не load-module module-alsa-sink в вашем /etc/pulse/default.pa .