Нахрена в API ПШШШШШШШШаудио xmalloc.h?

Да.

Да, или да?

Да, у него зачесалось. Ну как и обычно.

Почему ты не написал ему на почту с этим вопросом, а решил здесь посрать?

Сразу видно, ты не заглядывал в исходники gnu coreutils или подобного.

Вообще-то xmalloc (malloc, который не может вернуть NULL, а аварийно завершает программу при нехватке памяти) - это довольно таки стандартный прием. Прием полезен, так как код обработки ошибок при выделении памяти все равно не тестируется, и падать сразу будет, как минимум, честнее. Тем более, что на C++ падение (через std::bad_alloc) - это стандартное поведение при нехватке памяти.

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

Потому что если я назову ПШШШШШШШШаудио ПШШШШШШШШаудио — он обидится, а тут не заметит, наверное. К тому же, этот вопрос слишком тупой, чтобы донимать им человека, занятого великими делами.

ПШШШШ в нем, кстати, на некоторых кодеках от Realtek действительно был. Исправили, и даже в релиз (5.0) уже попало. Так что прошу больше не ляпать этот устаревший ярлык.

А исправили вот этим коммитом: http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=e6051cdf8db554c0...

Если бы ПШШШШЩаудио отучился лагать в doom3 - цены бы ему не было, а пока что killall -9 pulseaudio ; <run_what_you_need>

устаревший

ЩИТО? я вчера My Little Investigations запустил, так оно начало жрать проц и выдавать з в у к о в о е с л а й д ш о у.

Что-то это мне напоминает...

taskkill /F /IM explorer.exe
dmcr.exe
Start explorer.exe

Заглядывал, только при чём тут это?

Спрошу прямее. Нужно ли делать дубликат строки средствами пульсовского xmalloc.h перед передачей указателя на неё пульсовским API, например?

Вот же делать нефиг! Я просто макросы определил: макрос MALLOC вызывает calloc и в случае ошибки делает exit (в отличие от malloc, calloc гарантирует, что ты свои 2-3 гигабайта памяти, которые тебе жизненно необходимы для тяжелых вычислений, таки получишь! Либо сдохнет программа); макрос FREE вызывает free и приравнивает указатель к NULL (это тоже очень важно, т.к. по дефолту free указатель не обнуляет, что может привести к жестоким последствиям, особенно когда ты уже сделал free в теле функции в случае ошибки, а на выходе из функции опять free вызываешь).

Нужно ли делать дубликат строки средствами пульсовского xmalloc.h перед передачей указателя на неё пульсовским API, например?

Конечно нужно! Оно специальным образом помечает выделенную память, так что память выделенная всякими левыми аллокатарами не пройдет!

Вот же делать нефиг!
Я просто макросы определил: макрос MALLOC вызывает calloc и в случае ошибки делает exit

LOL

My Little Investigations

Посмотрел. Это полагается запускать в Wine. А во взаимодействии непатченного Wine и PulseAudio на USB-картах (или на других картах, где tsched не используется или выключен) действительно есть известный баг, приводящий к заиканию. Вот только заикание - это не шипение, давайте другой ярлык придумаем :)

Баг вот, только (неправильно) помечен как закрытый: https://bugs.freedesktop.org/show_bug.cgi?id=66962 - собственно, вся суть в первом комментарии. Wine требует у ALSA: «дай мне 4 буфера по 10 мс». ALSA-плугин переводит это на язык pulseaudio: «дай мне общую задержку 40 мс, и уведомляй каждые 10 мс», и, не дожидаясь ответа, говорит Wine «OK». PulseAudio с настройками по умолчанию на картах без tsched такое выдать не может, т.к. боится скушать батарейку. О чем честно сообщает ALSA-плугину. A глупый ALSA-плугин это съедает, т.к. уже сказал Wine, что все OK.

Workaround заключается в редактировании /etc/pulse/daemon.conf:

default-fragments = 4
default-fragment-size-msec = 5

Патч насчет смены умолчания я уже им посылал. Зарезали - типа не заметайте проблему под ковер, пусть пользователи страдают, пока не напишут хороший патч для ALSA-плугина. Чтобы он таки забирал данные из Wine по таймеру, а не когда это угодно PulseAudio.

Отвечу прямее. Результат работы функции pa_format_info_get_prop_string() полагается уничтожать с помощью pa_xfree().

т.к. боится скушать батарейку

Знач, если уменьшить буфер — будет кушать?

А чего он процессор нагружает-то так? Intel HDA 44,1k жуют только или 48k?

dmcr.exe

Слезу пустил

Я бы тем не менее назвал такое макрос CALLOC, так как любой читатель подумает что это просто вызов malloc без обнуления, но с какими-то дополнительными проверками

calloc гарантирует, что ты свои 2-3 гигабайта памяти, которые тебе жизненно необходимы для тяжелых вычислений, таки получишь

Ну-ну. Ты в курсе, что 2-3 гигабайта calloc будет получать через anonymous mmap — точно так, же, как их получает обычный malloc?

Сразу видно, ты не заглядывал в исходники gnu coreutils или подобного.

Студенты первокуры пишут код красивей и понятней, чем он есть в coreutils. Это вырвиглазие лучше никогда здоровым людям не видеть.

и що?

И то що разницы между malloc и calloc при больших размерах блоков (>= 128k) никакой. overcommit точно так же спокойно и замечательно может произойти.

Знач, если уменьшить буфер — будет кушать? А чего он процессор нагружает-то так?

Утверждается, что да. Энергия расходуется за счет накладных расходов на пробуждение и засыпание процессора. Впрочем, с моей личной точки зрения, утверждение о значительности таких расходов подлежит экспериментальной перепроверке, причем непосредственно по времени работы от батарейки в режиме проигрывания звука с различными размерами буфера. Тем более что тот же Андроид (мобильная ось, как-никак) со своим AudioFlinger'ом по умолчанию выставляет буфер в 10 миллисекунд и не боится - т.е. комично как-то получается.

Intel HDA 44,1k жуют только или 48k?

Теоретически зависит от конкретной Intel HDA. Но все, которые видел (кроме намеренно испорченной мной же в эмуляторе), жуют и 44.1 и 48 kHz.

Гордость нации не забывается? То-то я второго Ж.Д.А.Л.К.Е.Р.а не вижу.

тот же Андроид

Хороший пример, ага...

намеренно испорченной мной же в эмуляторе

Это как?

Таки фанат мой точно )

намеренно испорченной мной же в эмуляторе

Это как?

Специально внес изменение в исходный код QEMU, чтобы эмулируемая звуковая карта говорила операционной системе, что поддерживает только 48 kHz. Нужно было, чтобы объективно оценить искажения, вносимые ресемплерами в проприетарных операционных системах.

--- qemu/hw/audio/hda-codec.c   2014-07-06 18:46:20.764429441 +0600
+++ qemu/hw/audio/hda-codec.c   2014-08-20 21:58:32.661701409 +0600
@@ -114,7 +114,7 @@
 
 #define QEMU_HDA_ID_VENDOR  0x1af4
 #define QEMU_HDA_PCM_FORMATS (AC_SUPPCM_BITS_16 |       \
-                              0x1fc /* 16 -> 96 kHz */)
+                              0x040 /* 48 kHz only */)
 #define QEMU_HDA_AMP_NONE    (0)
 #define QEMU_HDA_AMP_STEPS   0x4a
 

Почему?