Высококачественный звук в Linux и в Linuх-подобных ОС

[Роман М]

Возможно баян, но хочется узнать на счет возможность реализации высококачественного цифрового источника на базе Linux и Linux-подобных OC, например Ubuntu, Android. В первую очередь интересуют следующие вопросы:
1) Поддержка USB Audio девайсов
2) Вывод аудиопотока с бит-перфектом
3) Поддержка losless и hi-res контента
4) Подходящие софтовые плейеры
5) Сравнение по качеству звука с виндой
У кого есть опыт просьба поделиться.

[Карта]

Планировщики отслушивать надо?

Смотреть крутизну фронтов.
А по теме (писал, вроде) - N лет назад экспериментировал, слушал штук 5 линуксов, один из них доставил. Хотя так быть не должно
Вообще, вся тема надумана.
Воспроизводить надо с хорошего железного плеера. Имхо, понятно.

---------- Сообщение добавлено 10:12 ---------- Предыдущее сообщение было 10:10 ----------

И, желательно, N-полосного.

---------- Сообщение добавлено 10:20 ---------- Предыдущее сообщение было 10:12 ----------

Припомнилось...
Есть у нас Сенсей, который 3.5 года целовал взасос некий Дшник, звук! Звук! И не реагировал на... советы.
Но потом реабилитировался, выдав красивую правильную фразу: "дыхания какого-то не хватает, что ли"...

[Alex]

Я не про это говорил (да и ошибаться могу, я что не человек что-ли?)

Когдя я ошибаюсь - с меня корона не упадет признавать мои ошибки.

[Meta|_]

Мы о гуишных ОС.

Вроде явно об этом до этого никто не писал ;)

Мне кажется, все так и делают, кому нужен настоящий жесткий реалтайм.

Настоящий жёсткий - это сколько? Ну, скажем, среднее/максимальное время отклика...

Иллюстрация 1.
Мы в одном проекте не так давно перешли с bare metal на FreeRTOS. Это позволило на порядок-другой уменьшить худшее время отклика для низкоприоритетных задач, при этом высокоприоритетные как выполнялись в прерывании (с теми задержками, которые может обеспечить процессор), так и выполняются.

Иллюстрация 2.
Приятель недавно плакался, что используемый им микроконтроллер иногда (очень редко) обрабатывает прерывание не как обычно - за 2-3 мкс, а за десять. Контроллер стоит в преобразователе питания на несколько кВт, и последствия бывают довольно серьёзны. Собирался переделывать весь проект на ПЛИС.

[Alex]

Приятель недавно плакался, что используемый им микроконтроллер иногда (очень редко) обрабатывает прерывание не как обычно - за 2-3 мкс, а за десять. Контроллер стоит в преобразователе питания на несколько кВт, и последствия бывают довольно серьёзны. Собирался переделывать весь проект на ПЛИС.

Это вместо того, чтобы с прерываниями разобраться?

Offтопик:

P.S. У нас тоже такое недавно было - алгоритмисты всунули новый алгоритм в проект, и OS перестала быть реалтаймовой Когда начали разбираться - они в высокоприоритетное прерывание всунули долго вполняюшуюся функцию, вместо того чтобы сделать форк с приоритетом пониже. Да еще и сама функция была как бы "сильно не отпимальной", и поставила колом всю систему. А все потому, что новая девочка тупо сгенерировала Си-шный код из под Матлаба, и даже не удосужилась посмотреть, чего он там нагенерировал.
Втык получила конечно не она, она только учится, что с нее взять, а руководитель ее группы.
Похожее было года полтора назад, когда изза еще одного "молодого" мы вдвоем просидели 3 или 4 дня, пытаясь понять аномальное поведение устройства в новом исполнении. в некоторых случаях. Симптомы были чисто "железными", причем чтобы их проявить нужно довольно много телождвижений и кучу времени (плюс извратиться припаять проводок к ножке QFN-чипа, чтобы повесить туда осциллограф). А предыдущее устройство, в котором эта "железная часть," абсолютно такая-же, не имело этих проблем.
И мы убили вдвоем столько времени, чтобы обнаружить что железо вообще не причем, а баг в новой прошивке, причем "детский" - вызов двух функции переставили местами. Поскольку в 99.99% случаев оно было бы пофигу. Но на оставшиеся 0.01% напоролись. Повторяю - симпомы были такие, что мы на 100% были что баг в железе на новой плате, а не в софте.

[_Summit_]

Когдя я ошибаюсь - с меня корона не упадет признавать мои ошибки.

Так и я вроде тоже. Ну посмеялся и хорошо. Мне все равно.

Настоящий жёсткий - это сколько? Ну, скажем, среднее/максимальное время отклика...

Да фиг знает. Я так представляю, это то время отклика, которое физ. предоставляет железо. По сути, в многозадачных системах процесс не имеет монопольного доступа к ресурсам (только когда он в режиме ядра). + еще маппинг памяти. Т.е. задержка там возникает как ни крути. Ядро, наверное, может не "отпускать" процесс или дать ему больше времени, но почему тогда это реалтайм или многозадачность?

Мы в одном проекте не так давно перешли с bare metal на FreeRTOS. Это позволило на порядок-другой уменьшить худшее время отклика для низкоприоритетных задач, при этом высокоприоритетные как выполнялись в прерывании (с теми задержками, которые может обеспечить процессор), так и выполняются.

Тут я не совсем понимаю.

[Alex]

Я так представляю, это то время отклика, которое физ. предоставляет железо.

Т.е. время, стремящееся к десяткам наносекунд, для высокоприоритетных прерывания, а то и меньше.

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

У тебя постоянно какие-то уточнения выозникают.
Сначало ты бредово заявляешь, что "в многозадачный операционных системах реалтайм не возможен".
Потом начинаются уточнения - только у ОС с гуем (с чего бы это?!), потом - только винда и пынгвын, теперь еще - "процесс не на уровне ядра".
А с какого бодуна реалтаймовый процесс с малым летенси, организовывать не в драйвере? Который работает непосредственно с прерываниями проца на регисторовом уровне?

+ еще маппинг памяти.

Какой нафиг "маппинг" и нафига он нужен?

Т.е. задержка там возникает как ни крути.

Да ничего там не возникает, так где это критично.

Тут я не совсем понимаю.

Потому что - см. выше, о твоих "уточнениях".

[Meta|_]

По сути, в многозадачных системах процесс не имеет монопольного доступа к ресурсам (только когда он в режиме ядра). + еще маппинг памяти.

Кажется докопались до корня непонимания Многозадачная ОС не обязана иметь "режим ядра" и "маппинг памяти", особенно это касается RTOSов. Тот же FreeRTOS - пример простейшей ОС, там ничего этого нет by design, однако многозадачность присутствует.

[_Summit_]

У тебя постоянно какие-то уточнения выозникают.

Никаких.

Сначало ты бредово заявляешь, что "в многозадачный операционных системах реалтайм не возможен".

Да я так думаю.

Потом начинаются уточнения - только у ОС с гуем

Я этого не говорил.

потом - только винда и пынгвын,

Этого тоже.

теперь еще - "процесс не на уровне ядра"

И что?

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

А где многозадачность?

Какой нафиг "маппинг" и нафига он нужен?

Для изоляции процессов.

Да ничего там не возникает, так где это критично.

Так ты про критично или релатайм? Даже если не раелтайм почти всегда не критично, кроме узких видов задач.
И прекращай приписывать мне то, что я не говорил. Или приводи цитаты.

---------- Сообщение добавлено 13:32 ---------- Предыдущее сообщение было 13:32 ----------

Кажется докопались до корня непонимания Многозадачная ОС не обязана иметь "режим ядра" и "маппинг памяти", особенно это касается RTOSов. Тот же FreeRTOS - пример простейшей ОС, там ничего этого нет by design, однако многозадачность присутствует.

Какими жертвами?

[Игорь Гапонов]

Насколько мне как дилетанту в этих ваших интернетах известно, USB-audio не корректирует каким либо образом ошибки в потоке обмена на USB-стороне, а просто их игнорирует (вроде даже не отмечая сам факт ошибки). И, слава Богу, хоть не принудительно интерполирует (обычное дело в читалках-плеерах CDDA-формата для некорректируемых по риду-соломону ошибок, причём, принудительно "по умолчанию" и хрен отменишь в контроллерах последнего поколения).

Возможно, что отличие в звуке осей связано ещё и с этим.

Алекс, поправь, у тебя больше опыта и знания (кажется, ты даже практически пытался ловить ошибки по USB-audio).

[Alex]

А где многозадачность?

В смысле "где"?
Ты не понимашь "что такое многозадачность"? Это когда одновременно работают несколько процессов

Даже в моих USB-интерфейсах крутиться 6-7 процессов параллельно, каждый на своем ядре и практически с нулевым летенси каждый.

Вот на столе девайс по работе.
Одновременно идет прием сигналов с датчиков, с очень малым летенси, стриминг данных на SD-карточку или в USB (смотря что подключено), далее несколько процессов обработки данных, с выводом на экран, плюс обработанные даные еще и стримятся по BLE на телефон, плюс обработка клавиатуры.
Это что, не многозадачность? Очень даже многозадачность, под реалтаймовой операционной системой, и без всякого "маппинга памяти" (там и памяти-то пол мегабайта RAM и два мегабайта ROM).

И прекращай приписывать мне то, что я не говорил. Или приводи цитаты.

ОК, тоесть - ты не имел ввиду только винду/пынгвына и ОС с гуем?

Тогда все еще веселее - "подравляю гаспадин соврамши".(с).

, USB-audio не корректирует каким либо образом ошибки в потоке обмена на USB-стороне,

Нет, не корректирует.
Хотя в UAC2 могли бы, но ворлде как и у UAC3 этого не сделали.

Алекс, поправь, у тебя больше опыта и знания (кажется, ты даже практически пытался ловить ошибки по USB-audio).

Именно что "пытался"
При нормальном USB-кабеле, на 44/16 мне их отловить не удалось - ни одной небыло в течении суток.
На 768/32 за ночь несколько проскочили.

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

Но есть у меня и говнокабель, с которым девайс в хайспиде часто определяется каа фулспид, с которым музыка потрескивает, а XTag/JTag (JLink) не работают вообще.
Еще одна из трез дырок USB в ноуте ведет себя примерно так-же.

---------- Сообщение добавлено 14:22 ---------- Предыдущее сообщение было 14:20 ----------

Возможно, что отличие в звуке осей связано ещё и с этим.

А у осей нет в этом различий, ибо оно определяется стандарнтом USB а не его конкретной реализацией.
Люба"нестандартности" особой проблемы, но так не делают.

[Игорь Гапонов]

Спасибо.

А у осей нет в этом различий, ибо оно определяется стандарнтом USB а не его конкретной реализацией.
Люба"нестандартности" особой проблемы, но так не делают.

Последнего предложения не понял...

Но оно ж (ось), например, при выполнении каких-либо операций параллельно с обменом по USB-audio может начхать на звуковой поток, как на "неприоритетный" ? Скажем, чтение с внешнего юэсби-носителя и выдача потока на внешний аудиодевайс через один контроллер-концентратор. Явно, что чтение файла с носителя будет иметь больший приоритет.

[AleXH]

А могут всплески ЭМИ при работе CPU вызывать наводки на импульсы клока, либо связанная с работой CPU пульсация питания генератора клока вызывать его "дрожь" по временной оси?

[Игорь Гапонов]

А могут всплески ЭМИ при работе CPU вызывать наводки на импульсы клока, либо связанная с работой CPU пульсация питания генератора клока вызывать его "дрожь" по временной оси?

Гены в процах все сплошь PLL, кроме двух (обычно) - "часовой" и "главный тактирующий". Последнему ваще-то в смысле работоспособности компа на джиттер начхать. Поэтому так хорошо слышен переход мастер\слэйв, например, в девайсах USBtoI2S. То, что вы указали актуально для "внутренних/набортных" ЗК. Самое печальное, что результат по сравнению звука набортных ЗК совершенно неоднозначный. Например, в моём Marsbord (проц A20 ARM) внутричиповое "звуковое ядро" на раз обыгрывает не внутричиповую риалтековскую на AMD-материнке, хоть для чипа риалтека используется "отдельный" кварц (задающий PLL сетки 44/48). А вот во внешних ЗК в слэйве уже хорошо слышны именно разные классы самих ЦАПов и их обвязок.

[_Summit_]

Одновременно идет прием сигналов с датчиков, с очень малым летенси

Малое латенси и РТ это одно и тоже?

ОК, тоесть - ты не имел ввиду только винду/пынгвына и ОС с гуем?

Нет, а где я это грил? Я предложил на примере ядра Linux, т.к. тема про него.

[JazMan]

Малое латенси и РТ это одно и тоже?

У РТ усреднённое время реакции даже больше, но стабильнее.

[blue sky]

А кто то использует в линуксе проигрыватель deadbeef? Играет детально, есть 18 полостный эквалайзер.

Вот так выглядит в слаке:

https://ibb.co/meD2Zy

Пишут что это "минималистичный плеер для ценителей хорошего звука".

[_Summit_]

У РТ усреднённое время реакции даже больше, но стабильнее.

Понятно.

[E.Sokol]

Не, чувак, ты путаешь прошедшее время с латентностью

Latency is a time interval between the stimulation and response.
Перевод:
Латентность применительно к прослушиванию музыки - интервал времени (time interval) между (between) тем, когда Гилмор извлёк ноту из своей гитары (stimulation) и тем, когда она достигла твоих ушей (response).

Шах и мат, латентофилы.

[Orion33]

В таком случае, она монотонно и неумолимо увеличивается)

[Игорь Гапонов]

Offтопик:
напр., латентная форма биполярного расстройства даже для самого расстраиваемого.

Собственно в цифири (дискретное время) она как минимум равна периоду дискретизации.