LINUX.ORG.RU

jack и Lisp


0

0

В общем мне было просто интересно написать что-либо на лиспе и как-бы взялся за то, что мне интересно. По этому рациональность выбранных средств не сильно волнует. В общем задача взять звук, обработать и вывести в реальном времени. Пока-что просто пытаюсь выводить звук без изменений. Написал биндинги к нужным функциям. Вроде работают. То есть я нормально создаю клиент и подключаюсь к джек серверу иникиализирую входной и выходной порт нормально передаю callback функцию. Но при попытке инициализировать работу путем: (jack-activate client) у меня лисп сегфолтится( использую SBCL на gentoo_amd64). Исходник вот: ftp://kawais.org.ua/incoming/jack.lisp Аналогичная программа на С работает безупречно. Пробовал писать простенкие примеры с callback функциями и тоже работают. Честно говоря даже не знаю, как это дело дальше копать. Посоветуйте что-нибудь, пожалуйста.

Сервер джека при этом пишет: 20:16:00.125 JACK connection change. 20:16:00.126 JACK connection graph change. 20:16:00.126 XRUN callback (1). subgraph starting at qjackctl timed out (subgraph_wait_fd=17, status = 0, state = Running, pollret = 0 revents = 0x0) **** alsa_pcm: xrun of at least 1958.740 msecs 20:16:00.328 JACK connection change.

ЗЫ пример вот от сюда http://www.valkama.se/article/lisp/sbcl-sy-1/ сегфолтится также.

★★★★★

А jack не вызывает этот callback в другой нитке? В sbcl коллбэки могут вызываться только из ниток, созданных самим sbcl. Пару дней назад похожая тема была поднята в comp.lang.lisp про SDL Audio.

dmitry_vk ★★★
()

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

makoven ★★★★★
()

>А jack не вызывает этот callback в другой нитке?

Честно говоря я не очень хорошо знаю внутренности jack. Но посмотрю.

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

Не знаю, как еще связать их. Либо всю обработку писать на С, а лиспом только контролировать... Но мне хотелось бы непосредственно это делать в лиспе. И тут без коллбека я не знаю, как обойтись

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

>>Не знаю, как еще связать их. Либо всю обработку писать на С, а лиспом только контролировать... Но мне хотелось бы непосредственно это делать в лиспе. И тут без коллбека я не знаю, как обойтись

Не знаю, как это обычно делается, но подозреваю, что на лиспе надо писать структуру приложения (предварительно убив 15 лет на CLOS и MOP) чтобы потом в лиспе делать (play "file"). А play привязать к чему-нибудь на си, что связывается с джаком, OSS, ...

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

> Честно говоря я не очень хорошо знаю внутренности jack. Но посмотрю.

Посмотрел на ваш исходник. Судя по вот этому:
> (jack-activate client)

> (read)

> (jack-client-close client)

похоже, jack создает нитку и из нее вызывает переданный callback (т.к. (read) блокирует текущую нить). Было предложено следующее решение: нужно сделать не-лисповый callback (например, на Си), который, например, через пайп будет общаться с лиспом (в фоновом потоке); и в jack передавать уже этот callback.

dmitry_vk ★★★
()

>Было предложено следующее решение: нужно сделать не-лисповый callback (например, на Си), который, например, через пайп будет общаться с лиспом (в фоновом потоке); и в jack передавать уже этот callback.

Я вот не уверен на счет задержки... Насколько пайпы быстрые? Тут дело на 10-ки милисекунд

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

Хм.. и вообще я не очень понимаю, почему возникают проблемы при сздании еще одной нити для вызова коллбек функции?

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

Задержки, да, могут доставить неприятности.

>Хм.. и вообще я не очень понимаю, почему возникают проблемы при сздании еще одной нити для вызова коллбек функции?

Нужно определенный образом среду времени исполнения лиспа подготовить к тому, что будет выполняться код в нити. Например, нужно создать в ней биндинги динамических переменных, как-то приготовить сборщик мусора к тому, что имеется новая нить с лисповским кодом и пр. В чем именно проблема с sbcl, я не знаю. Некоторые другие лиспы поддерживают вызов коллбэков в «чужих» нитях.

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

Цитата из документации sbcl несколько проясняет:

«On x86 the per-thread local bindings for special variables is achieved using the %fs segment register to point to a per-thread storage area. This may cause interesting results if you link to foreign code that expects threading or creates new threads, and the thread library in question uses %fs in an incompatible way. On x86-64 the r12 register has a similar role.»

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