Помогите подобрать платфлорму

[bjack]

С новым годом)
Люди добрые, подскажите железку под следующие требования:
1. linux (тут нужен LAMP и должно хватать сил на ffmpeg по скриптам в консоли) с GUI (от гуя хочется: воспроизведение аудио и вебморду для того что живет на LAMP)
2. ethernet и com (хочется настоящий, а не через usb)
3. соответственно выход на монитор (любой, от VGA до HDMI)
4. поддержка sata или M.2 (нужна возможность замены)
5. самое интересное - внешний вход, который будет дергать систему не реже 10 раз в секунду

Чтобы было понятнее железка планируется для такого использования:
1. через вебморду скармливаем аудио
2. аудио посредством ffmpeg + audiowaveform разбирается на запчасти и складывается в mysql
3. когда приходит время, запускается воспроизведение аудио
4. при воспроизведении, не реже 10 раз в секунду читает mysql и посредством modpoll вываливает наружу
Последнее чисто теоретически можно организовать из вебморды. Но js не гарантирует соблюдения интервалов, поэтому и возник 5 пункт хотелок. Мечта прицепить ногодрыг на ардуинке к gpio и пусть молотит.
Режим использования - 24/7 в течении ~7 месяцев

[Olej]

1. через вебморду скармливаем аудио
2. аудио посредством ffmpeg + audiowaveform разбирается на запчасти и складывается в mysql

Не очень понятно что такое "разбирается на запчасти" (по какому принципу), но для загаданных вами целей потоковой обработки потребуется достаточно высокая производительность ... + хорошо бы иметь запас который завтра захочется иметь.

Поэтому первое, что можно посоветовать: не покупайтесь на кажущуюся дешевизну ARM архитектур ($30 и больше), посмотрите из числа одноплатных x86 (Intel), там вполне можно найти совершенно подходящие приличные модели в диапазоне цен порядка $100-130.
Что-то по типу такого, см. тему x86

[Olej]

5. самое интересное - внешний вход, который будет дергать систему не реже 10 раз в секунду

Описали бы замысел и идею подробнее?

Последнее чисто теоретически можно организовать из вебморды. Но js не гарантирует соблюдения интервалов, поэтому и возник 5 пункт хотелок. Мечта прицепить ногодрыг на ардуинке к gpio и пусть молотит.

В Linux можно организовать в достатке таймеры с большой точностью, для этого не нужны какие-то внешние механизмы.
См. темы GPIO в Linux и GPIO

Ни в коем случае не впутывайте в одну конструкцию Linux/x86/ARM c Arduino ... и даже не потому что Arduino - это игрушка и чем-то плох, но это совершенно разнородные системы.
См. тему Arduino

[Olej]

2. ethernet и com (хочется настоящий, а не через usb)

1. Ethernet присутствует практически везде, даже на самых усечённых моделях.

2. Для COM вполне прилично (по многочисленному опыту) использовать внешние устройства, типа таких как описано в теме загрузчик U-boot и сериальная отладка


Ценой <= $2

А аппаратные COM, с разъёмом RS-232, присутствуют только на устаревших моделях, и это должно настораживать.

[bjack]

Не очень понятно что такое "разбирается на запчасти" (по какому принципу), но для загаданных вами целей потоковой обработки потребуется достаточно высокая производительность ... + хорошо бы иметь запас который завтра захочется иметь.

Там не потоковый разбор, а разовый: берем mp3, распиливаем ее, при помощи ffmpeg, потом полученные файлы скармливаются audiowaveform и на выходе получается набор json файлов (по сути амплитуды частот, с заданной дискретностью) уже эти файлы перегоняются в mysql. Все промежуточные файлы - dev/null. До этого момента 2 малинка не напрягается. Это по сути подготовка к работе, тут можно было и не торопиться - времени сколько угодно.

Ну а потом собственно начинается исполнение - нужно воспроизвести исходный mp3 (можно его при подготовке "разжать" в wav, это не существенно) и при воспроизведении синхронно читать данные из mysql и выкидывать их на устройства modbus (modpoll на той-же 2 малинке достаточно производителен)
Проверено на com порту малинки, насколько понимаю - он там аппаратный.
В тестовом варианте (аудио воспроизвожу браузером, на самой малинке, запросы к БД пытался генерировать из него же) уже видно, что интервалы плывут (воспроизводится нормально, проблема именно в неравномерной генерации событий js). Про таймеры в Linux почитаю, но подозреваю что не прокатит (слишком глубоко надо залезть от уровня ОС к железу, чтобы эта самая ОС на них не влияла)
Адаптеры с картинки мне знакомы, насчет RS232 только на устаревших моделях - Вы горячитесь))) HP выпускает материнки под i7 с com портом
Малинка кстати не нравится еще и потому что ethernet в них через тот же usb заведен.

[Olej]

HP выпускает материнки под i7 с com портом

Выпускает, но изредка - это скорее экзотика.

[Olej]

Ну а потом собственно начинается исполнение - нужно воспроизвести исходный mp3 (можно его при подготовке "разжать" в wav, это не существенно) и при воспроизведении синхронно читать данные из mysql и выкидывать их на устройства modbus (modpoll на той-же 2 малинке достаточно производителен)

Зачем такое надо - всё-равно не понятно.

уже видно, что интервалы плывут (воспроизводится нормально, проблема именно в неравномерной генерации событий js).

Насколько сильно "плывут"? (джиттер, в %, или по распределению)
Абсолютной привязки к периодическим синхроимпульсам вы не добьётесь никогда, реализуя это хоть программно, хоть аппаратно от внешнего задатчика - это многозадачная операционная система, у которой происходят одновременно разные процессы выполнения с разными приоритетами...
Такая жёсткая детерминированность событий была бы свойственна операционной системе реального времени, но таких в обиходе уже не осталось. За ненадобностью, наверное ... потому что все, приходящие из мира аппаратных решений (схемотехники), попервах требуют жёсткой абсолютной привязки к временной шкале, а потом оказывается, что такие требования вытекают из ошибочности постановки задач. В мультизадачной ОС должны реализовываться несколько другие решения.
P.S. Можете в связи с этим посмотреть Raspberry Pi: hard realtime Linux/Xenomai и Xenomai и real-time Linux - это следы реальной работы, и там приводились ссылки на обсуждения, где приводились графики джиттера временных итервалов в Linux.

[bjack]

Насколько сильно "плывут"? (джиттер, в %, или по распределению)

"Хорошо" плывут))) до 300мс на тойже многострадальной малинке доходило

Зачем такое надо - всё-равно не понятно.

Светомузыкальные эффекты. Только не надо сейчас про DMX рассказывать))) Штука хорошая, но скорости в поставленной задаче не хватает.

Такая жёсткая детерминированность событий была бы свойственна операционной системе реального времени, но таких в обиходе уже не осталось. За ненадобностью, наверное

Да RTOS, отлично подходит. И опять же широко распространены, как и аппаратные COM порты , (называется ПЛК), просто не в сфере Ваших интересов )
Но готовые решения натыкаются на следующие грабли:
1. хранение достаточно большого объема данных с надежным оперативным доступом в процессе исполнения
2. легкость модификации этих данных
3. гибкость изменения алгоритма реагирования

Решение задачи, путем RTOS:
Ваяем на микроконтроллере (у ардуинки дури скорее всего не хватит, возьмем stm32 наверное из 400 серии).
Медиафайлы и алгоритмы работы храним на sd картах (закрываем глаза на надежность)
АЧХ получаем аппаратно, в процессе воспроизведения (msgeq7 нам в помощь), можно и программно но смысла нет
Плюсы:
1. все аппаратное

Минусы:
1. Объем разработки (GUI, протоколы исполнительных устройств...)
2. Производство железки (да испытать "концепцию" можно на макетке и рассыпухе, но готовое изделие придется делать не из шилдов)
3. Отсутствие возможности "предпросмотра"

Железка с linux выглядит привлекатетельнее

[Olej]

Минусы:
1. Объем разработки (GUI, протоколы исполнительных устройств...)

Это практически безнадёжно, это только из области "мечтов" может быть.

[Olej]

И опять же широко распространены, как и аппаратные COM порты , (называется ПЛК), просто не в сфере Ваших интересов )

С PLC я работал (в рамках служебных обязанностей, некоторое время), Siemens & Schnider Electric ... Но там ничего особенного RT нет, там просто всё строится на том, что там однозадачная MS-DOS + всё крутится в бесконечных циклах программного опроса... а всё остальное - это мистификация не очень понимающего пользователя от крутых бранднеймов.