Neo, наконец-то добрался я до HiAsm, посмотрел Вашу схему и могу настоятельно рекомендовать Вам поосторожнее ставить действия по onEndPlay (Вспоминаем старый добрый SafeMode )

Это не Ваша вина, что Вы не знали, но всё после onEndPlay принадлежит ОТДЕЛЬНОМУ ПОТОКУ, так что этот код исполняется параллельно потоку основному и не известно, к чему может привести, тем более, вы из этого потока обращаетесь к самому же плееру, правда, через таймер.

nesco, я так понимаю (не могу сейчас проверить), даже при регистрации таймера в контексте отдельного потока, процедура onTimer будет отрабатываться в контексте оконной процедуры (т.е. основного потока)?

Для меня он старый ЗЛОЙ СЕЙФМОДИЩЕ
У меня о нем мнение, что если их поставить 2 с одинаковыми названиями и Wait на двух потоках, сходящихся к одному элементу, он не даст им наложиться друг на друга. Я пока так и не поборол лень проштудировать эту функцию.
И не понимаю как он защитит программу от сбоя. Ведь этот onEndPlay наплодит кучу потоков? Или они завершатся и все нормально? Тогда зачем ставить SafeMode, если mp3 отыграл, а по таймеру (пусть и в новом потоке произведен запуск системного таймера, что не айс) задается еще один раз отыграть те же данные, которые есть в памяти компонента.

Да.

nesco, получается, вставляя таймер в любом месте отдельного потока, мы получаем синхронизированный с основным потоком итерации?

Если не ошибаюсь, тут все события Timer.onTimer вызываются обработчиком сообщений в контексте оконной процедуры. То есть можете считать это воображаемой "точкой", выходящей из MainForm (даже если таймер трижды вложен в контейнера и регистрируется параллельным потоком). Например, у моего плагина qsearch нет своей формы (он вообще является dll-библиотекой), но это не мешает ему зарегистрировать в системе таймер. Система с указанными ей интервалами присылает обработчику HiAsm сообщения с указанием процедуры в моей библиотеке, которую нужно вызвать. Соответственно, вызов происходит в контексте конструктора, при желании я могу поковыряться в его памяти. По этой же причине я долго не хотел пользоваться таймерами и в любой момент готов их убрать - мало ли, конструктор запустит мой плагин в отдельном потоке и часть после таймера получит шанс одновременно обратиться к памяти, используемой остальным плагином. Там видна перестраховка в виде SafeMode, по хорошему там я бы ещё парочку поставил

А будет ли верно, если я запущу под проигрывание звуков отдельное приложение (возможно имеет смысл без формы?), которое будет по TCP получать команды на проигрывание из параллельного потока основной программы? Будет записывать их себе в очередь, и обрабатывать потихоньку в основном потоке, не вешая при этом главную программу. Думаю основную программу разгрузить от потоков и повысить отказоустойчивость.
------------ Дoбавленo в 16.20:
Или эта мысль от лукавого и никакого смысла нет?

Некоторые модульные программы так и поступают. Например, браузер Chromium и его потомок Google Chrome умеют запускать отдельное приложение на каждую вкладкустраницу. Один из мотивов - изоляция друг от друга, если одно зависнетвылетит по каким-либо причинам, остальные продолжат работу как ни в чём не бывало.

Кстати, в моем комплексе тоже сервер обработки отделен от потенциально тормозящих модулей. Связь между модулями производится по UDP, как более быстрого, чем TCP канал. Лучше всего пошли бы PIPE, но их у нас пока нет

Подскажите еще как лучше читать UDP: через Thread, или ручной?

AFAIK, два кардинально различных подхода. В первом случае при приёме данных должен породиться поток с onReceive. Во втором случае ничего не произойдёт, пока самостоятельно не будет вызван метод doReceive, схема после onReceive будет принадлежать потоку, вызвавшему метод. (да, и тут без потоков не обошлось ).

Вынес в отдельную программу по UDP все вязаное со звуком (BASS и простые компоненты) - уже почти сутки работает без сбоев. Правда был сбой с UDP: если выслать данные которые некому принять - вылетала ошибка и закрывалось все. Решил это, вставив стек, после onReceive - видать он выдает туда какую-то служебку, в случае неподтверждения приема отправленных данных.

Итак, добрался до вышеупомянутой ошибки из-за внедрения UDP. Она появляется при закрытии программы и упорно меня раздражает
http://forum.hiasm.com/forum_serv.php?q=56&id=2702 - вот этот коварный тип! Пропадает, если отключить точку onReceive от UDP. Что-то можно сказать по этим симптомам? Это уже какой-то Exception

Neo, файл форум потерял в параллельной Вселенной. Что там у Вас вылетает, "музыкальная" часть или основная, "заказывающая" музыку? Где схема, по которой не имеющий Вашего оборудования сможет воспроизвести проблему у себя и изучить?

Хех, не одну мою пикчу потерял форум!

Вылетает и основная и параллельная часть, если точку onReceive использовать без ухищрений со стеками - с ними вылетает только основная часть при закрытии. Но связь между блоками у меня двусторонняя. Если точку отключить совсем - ничего не вылетает.
Мне бы хватило и скромного пинка на возможную причину ошибки, если можно предположить оную по инфе из ошибки. Выдавать схему всю и заменять всякие там мои ежедневные доделки -переделки будет несколько проблематично. Да и не факт, что у кого-то ошибка будет повторяться из-за разности оборудования и т.п.. Да и как-то неудобно давать на разбор схему в 1 метр весом - кому нужно лезть в эти дебри, неискушенного красивым рисованием схем, HiAsmовца?

Дайте мне .exe неупакованный с этой ошибкой и скриншот ошибки именно этого exe, естественно, скажу, в каком месте она проявляется и по каким вероятным причинам.
Хотя уже сейчас можно с большой вероятностью делать выводы, что дело в преследующих Вас всюду потоках Все копии веток по onReceive при ReceiveMode=Thread исполняются в параллельных потоках. Видимо, при закрытии приложения что-то, к чему этот поток обращается, удаляется из памяти раньше, чем завершится поток. Попробуйте вызывать перед закрытием doClose.