LINUX.ORG.RU

[ALSA] Проблема в связке ALSA + Audigy SE

 


0

0

В общем, я всё же купил именно эту карту, и она оказалась ощутимо лучше, чем Via Tremor, поэтому отказываться от неё не вариант. Итак, звучит всё отлично, но в случайные моменты может «рваться» на долю секунды звук, при этом в консоль пишется

ALSA lib pcm.c:7223:(snd_pcm_recover) underrun occured
Как избавиться, не трогая версии alsa и ядра?

Пробовал увеличить буфер до 16384, но не помогло. В OSS4 проблемы нет, но там звук хуже. Также проблема решается установкой Pulseaudio, но нужно повозиться с настройкой ресэмплинга и вообще не хотелось бы использовать лишнюю прослойку из-за какого-то бага.

Техническая информация:

[~] >> aptitude versions alsa-base
i   1.0.23+dfsg-2                                 stable                    500
[~] >> uname -a
Linux Persephone 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 GNU/Linux
[~] >> cat /etc/debian_version
6.0.3

В /etc/asound.conf и ~/.asoundrc всё закомментировано.

★★★★★
Ответ на: комментарий от anonymous

Хорошо, сейчас поищу документацию.

GotF ★★★★★
() автор топика
Ответ на: комментарий от coldy

Ok, если твики asoundrc не помогут, то попробую.

GotF ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Установка period_size в 4096 (предел) не помогла.

GotF ★★★★★
() автор топика
Ответ на: комментарий от coldy

Смешно не будет — не помогло.

GotF ★★★★★
() автор топика

Выяснилось, что в более поздних ядрах/ALSA проблемы нет (проверялось на 2.6.37/1.0.24). Попробую ещё поиграться с настройками dmix, если не получится, то пока буду использовать OSS4.

GotF ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Угу, погугли «stutter» на двух ALSA wiki, будешь удивлён. Я вполне допускаю, что этот косяк дебианоспецифичный, но это далеко не факт.

Кстати, кажется, нашёл наименее страшный способ вылечить проблему: режим эмуляции OSS и соответствующая настройка программ.

GotF ★★★★★
() автор топика
Ответ на: комментарий от sumrak_ss

Ядерная. Уже выяснено, что проблема, скорее всего, в конкретных версиях. Сейчас запилил ядро из бэкпортов, потестирую звук.

GotF ★★★★★
() автор топика
Ответ на: комментарий от GotF

Сейчас запилил ядро из бэкпортов, потестирую звук.

Та же петрушка. Похоже, дебианопроблемы.

GotF ★★★★★
() автор топика
Ответ на: комментарий от GotF

Похоже, эта карта в дебиановском ядре теряет прерывания. Гипотеза подтверждается тем, что с pulseaudio (который прерывания не использует) у тебя все работает, как надо.

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

Т.е. нужны действия, прямо противоположные предпринятому ранее увеличению размера периода :)

Итого:

1) стереть .asoundrc

2) aplay -v -f dat /dev/zero (будет играть тишину)

3) посмотреть на поля buffer_size и period_size в получившемся отчете, вычислить periods = buffer_size / period_size

4) прописать их в .asoundrc, примерно так (строку вместо Audigy2 взять из квадратных скобок в /proc/asound/cards):

defaults.dmix.Audigy2.!periods 8

defaults.dmix.Audigy2.!period_size 1024

(насчет необходимости восклицательного знака не уверен)

5) удвоить periods и, возможно, вдобавок к этому потребуется поделить period_size на 2 (смотря что лучше сработает)

6) проверить с помощью aplay -v -f dat /dev/zero, применились ли настройки

AEP ★★★★★
()
Ответ на: комментарий от AEP

удвоить periods и, возможно, вдобавок к этому потребуется поделить period_size на 2 (смотря что лучше сработает)

Увы, не помогло. Дальнейшее удвоение/деление параметров тоже не помогает. Частота запинок меняется, но даже в лучшем случае они могут происходить каждые 1-3 минуты.

Есть ещё варианты? OSS меня в основном устраивает, но там тоже есть крайне неприятные косяки, хоть и в других местах. Если больше ничего не сделать, то поставлю pulseaudio, надо только разобраться с передискретизацией — там обязательно используется своя, плюс dmix…

GotF ★★★★★
() автор топика
Ответ на: комментарий от AEP

И ещё непонятно, как oss-compat решает проблему? Ведь это всего лишь модули, предоставляющие /dev/dsp и /dev/mixer? Возможно, дело в разнице между способами работы приложений с ALSA и OSS?

GotF ★★★★★
() автор топика
Ответ на: комментарий от GotF

Ставь pulseaudio. С передискретизацией там разбираться долго не надо, там за нее отвечают только два очевидных параметра в daemon.conf: resample-method, который надо оставить в speex-float-3 или, если услышишь разницу, поднять до speex-float-5, и default-sample-rate, которая по умолчанию 44100 Hz и которую можно поменять. По взаимодействию с dmix тоже думать не надо, поскольку при наличии pulseaudio dmix (и, соответственно, его настройки) просто не используется.

oss-compat решает проблему путем изменения логики передискретизации на менее точную по времени. Вероятно, баг в каком-то конкретном приложении, которое открывает plug:dmix с двумя программными периодами (не путать с аппаратными периодами, число которых мы пытались удвоить), а такое при наличии точного ресемплера между приложением и картой работать просто не может.

AEP ★★★★★
()
Ответ на: комментарий от AEP

Ставь pulseaudio. С передискретизацией там разбираться долго не надо, там за нее отвечают только два очевидных параметра в daemon.conf: resample-method, который надо оставить в speex-float-3 или, если услышишь разницу, поднять до speex-float-5, и default-sample-rate, которая по умолчанию 44100 Hz и которую можно поменять. По взаимодействию с dmix тоже думать не надо, поскольку при наличии pulseaudio dmix (и, соответственно, его настройки) просто не используется.

Да, с PA я разобрался, по настройке проблем нет. Однако с ним тоже не всё хорошо — при переключении треков или перемотке в MPD, последний часто зависает, не реагируя на SIGTERM. В общем, я поставил JACK — проблем пока не наблюдается, всё довольно просто. Ресэмплинг до нужных карте 48 КГц поручил MPD (libsamplerate), в mplayer звук работает и ладно.

oss-compat решает проблему путем изменения логики передискретизации на менее точную по времени. Вероятно, баг в каком-то конкретном приложении, которое открывает plug:dmix с двумя программными периодами (не путать с аппаратными периодами, число которых мы пытались удвоить), а такое при наличии точного ресемплера между приложением и картой работать просто не может.

А, вот как оно. Насчёт бага в одном приложении сомневаюсь — исчерпание буфера наблюдалось в самых разных программах.

GotF ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.