ampir-nn

Это просто ваше мнение, ничем не обоснованное. По вашим принципам, смартфон или корманный мп3 плеер - идеальный источник цифры. Возьмите осицил. и проверьте ваши выводы, нет никаких помех и наводок, если у вас не супербюджетная мать и БП. А джитер всей системы влияет на звуковую систему, это факт ..... Софт плеер не может оказывать влияния на звук в правильно настоенной системе - тоже факт. А прерывания у вашего контроллера "равномерные" ? Вообще все что выше, каша из теории ....

А вы думаете что оперативная память ровнее чего-то там ... , например, семплы выдает с памяти операционная система, но она кривая (по умолчанию она для юзеров) и рассинхронизирована с ЗК ... плюс сама система (в общем с посредственным железом) имеет очень-очень огромный джиттер. Решение проблемы - минимальный возможный буфер, минимум для Linux - 4 семпла в два периода, при 88200 получается, что ПК выдает семплы с относительно большой временной стабильностью, т. е. в "реальном времени" ... А что получаем в итоге - это кристально чистая верхняя середина и ВЧ, ну как с Астра 110 когда-то ... Но, на USB устройствах, я думаю что это не будет работать, т. к. в современных USB ЗК стоит свой чип с FIFO, который накосячит поболее более ПК, с преумножением онных ..... в зависимости от шнуров и .... Всё ... Таких устроуств не существует, вообще... Или попробовать перенести SD-карту на перфо-карту, возможно и получится, последовательное чтение https://ru.wikipedia...wiki/Перфокарта

Минимальный LInux усатановленный на флешку, после загрузки системы, обращений к флешке нет, вообще. Флаки на жестком диске. Подробнее в соседней теме.

В Win диск постоянно работает, в Lin нет. Установите ОС на флешку, Windows и Linux, сравните и вопросов больше не будет. Win для работы с офисом и прочей не проф. ерундой Все считовается cс носителей в свободную оперативную память, с опережающим кешированием (preload). Пофигу на режим работы плеера, первые секунды есть обращения к диску, последующие минуты их просто нет.

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

В Linux все грузится в оперативную память, все что вы использовали или обратились хоть раз, без зависимости настроек плеера или другой программы ... Вы его запустили (любой скрипт или прогу), он уже в оперативке, обратились к файлам на HDD - и они уже в памяти с пред (preload) кешированием ... В Linux все крутится в оперативке, с preload, почти 90% памяти отдается под кеш, читайте .... Неужели вы думаете что ОС считывает данные с носителей побитно ???

Данные подгружаюся в оперативку ..... А какое влияние могут оказывать на данные, питание и прочее ... SDD или HDD ? Какая разница как и откуда поступают данные ? То что происходит с цифрой, после загрузки в память ОС - имеет значение .... но до этого пусть хоть что угодно, были бы целы "данные" .... Загрузите все в оперативку, т. е. ОС и файлы - будет типа полный фен-шуй, но разницы нет никакой, проверил 17 раз И кто сказал что оперативка "шумит" меньше HDD или LAN ? Отремонтирую скоро осциллограф, много вопросов отпадёт.

Да уж, посмотрел, только интерфейс MOC это более 4000 строк кода

Да уж, это не Win - но жизни не хватит

Нет такого, в нормальной системе. Сделайте консольный интерфейс, как в MOC плеере - очень удобно, и по моему даже удобнее любой графики. 100% правильный подход. Дело даже не в HDD, а потому как - без сети ну не как, нужно настраивать обязательно. Сеть гадит не больше USB ... COM, клавы-мыши и т. д. .. а может и меньше

В Linux будет работать любое оборудование, даже самое древнее.

Windows может захватывать, но не может их полностью изолировать от системы, при загрузке ... У меня система работает на двух ядрах, а два полностью свободных только для аудио.

Я и пишу и автор статьи, попробуйте и увидите какой фазовый бардак вам выдаёт звуковая система на вход ЗК. И потом увидете зависимость этого бардака от размера буфера. Там автор в начале статьи пишет что его устройство значительно улучшает качества звука по сравнению с стандартным ALSA, потом это обосновует измерениями и математикой ... Правильная синхронизация - аппаратная ==== давай, попробуй, синхронизируй комп с десятками прграммных и железных клоков - с ЗК, без того про что пишет автор, аппаратно Или самый простой вариант - это побитовый вывод на ЗК, но с нагрузкой на ЦП.

Нет, я про стандартное ядро без урезанных функций, и с возможностью закрузки на любую систему Под конкретную систему можно собрать в 100мб, моё ядро с модулями 40мб, дефолтное в десять раз больше, но моё ядро на вашем пк не не будет работать .... И какой смысл в этом, что памяти не хватает ?

Не факт, даже при отсутствии сторонних нагрузок по умолчанию - будет полный временной бардак в системе, т. к. система настроенна на выполнение сотен процессов одновременно, по умолчанию. При правильной организации всех процессов, обратите внимание буфер всего 4 семпла Третье и нулевое ядро это звук, два остальных - общяюсь с вами в Firefox. Видно что нагрузка не влияет на джитер всей системы, конкретно вывод с ядром 0.

Я думаю что через год, уже ядро Linux будет с gui по умолчанию Сейчас ресурсы не ограничены ни чем, почему их не использовать? Смысл в консольном варианте?

Идеальный вариант - ваш плеер, с минимальным универсальным оптимизированным ядром Linux (с возможностью выбора звуковой системы OSS4 или ALSA, ALSA+JACK, ALSA+JASK+ ...... при загрузке), загрузка системы с флешь карты в операционную память ПК ... Универсальное ядро + минимальный gui = ~ 800мб в памяти, на флешке образ примерно ~ 300- 400мб. Был такой медиа плеер на ядре Linux, лет десять назад - загрузка с CD (журнал "Хакер" ~2003г), без установки на жесткий, в 100мб размером ...

Вы очень уважаемый человек в круге аудио, к вашим выводам многие прислушиваются и считают за истину ... ALSA не что иное как набор драйверов и примитивный микшер с утилитами. Например истема OSS4 в отличее ALSA намного лучше устроенна из за работы с памятью, качественным микшером и ресемплером, хотя сами драйвера почти на 100% одинаковы в всех системах Unix. В FreeBSD звуковая система - это полный аналог OSS т. е. дальнейшее её развитие разработчиками FreeBSD, тоже намного лучше организованна чем звуковая система ALSA, она ближе к Coreaudio. Jack это конфигуратор драйвера ALSA и всей звуковой системы вплоть до организации работы драйвера с памятью. Jack работает с драйвером ALSA на самом низком уровне. Вот вывод конфигурации драйвера ALSA с помощью Jack: JACK server starting in realtime mode with priority 99 creating alsa driver ... hw:Audiophile192,1|-|32|8|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 32 frames (0.7 ms), buffer = 8 periods Я не спорю, возможно сконфигурировать систему с помощью плеера, но это очень сложно и долго, хотя можно взять часть кода из Jack ... но какой смысл привязовать всю звуковую систему к одному пусть и очень хорошему плееру. В плане зависимости джиттера от частоты и нагрузки ЦП, чем выше частота процессора тем система стабильнее т. к. частота системного таймера зависит от частоты ЦП. При правильных настройках системы, а их в Linux очень много нагрузка на ЦП в разумных пределах на стабильность и джиттер не влияет, могу все подтвердить реальными измерениями Сделайте пожалуйста модуль вывода в Jack, как у всех аудио плееров, в дальнейшем ...

Вот читаю тему, после упоминания в ней Linux - просто цирк какой-то. Вы хотя бы разобрались, как устроена сама система Linux и звуковая система начиная с первого варианта OSS. Потом, вы что не читаете соседнюю ветку ? Там сайт http://kokkinizita.linuxaudio.org/ и статья упомянутая вами обсуждалась раз двадцать .... Про джитер создоваемый Jack, это в корне не правильно.

Мин буфер ограничен драйвером ALSA, например для ice1724 Из исходника драйвера static const struct snd_pcm_hardware snd_vt1724_playback_pro = { .rate_min = 8000, .rate_max = 192000, .channels_min = 2, .channels_max = 8, .buffer_bytes_max = (1UL << 21), /* 19bits dword */ .period_bytes_min = 8, 4, 2, /* FIXME: constraints needed */ .period_bytes_max = (1UL << 21), .periods_min = 2, .periods_max = 1024, Самый минимальный работоспособный буфер 4/2 - 44100, 88200 ... 0,1 мс - 0 HDA драйвер с менее 32/2 не запускается и т. д .... Отличие ALSA и ALSA + Jack Specific Host API Implementations JACK Buffering model: Opaque host managed Buffering latency: bufferSize Buffer size constraints/restrictions: fixed buffer size Buffer size constraints expressed as: fixed??? Device and system latencies: Each node can query for input and output latency (see below) Exposes preferred or default latency: N/A Unknown latencies: i/o latency is dependent on correct user calibration Provides actual device sample rate: fixed sample rate??? PA callback invoked by: callback Native full duplex: YES May use host/user buffer size adaption: YES May use full-duplex synchronisation buffering: NO May introduce SRC latency: NO ALSA Buffering model: ? Buffering latency: ? Buffer size constraints/restrictions: ? Buffer size constraints expressed as: ? Device and system latencies: N/A Exposes preferred or default latency: ? Unknown latencies: Hardware buffering and A/D latencies Provides actual device sample rate: ? PA callback invoked by: ? Native full duplex: ? May use host/user buffer size adaption: ? May use full-duplex synchronisation buffering: ? May introduce SRC latency: ? Вот здесь тоже немного про работу ALSA http://kokkinizita.l...quickguide.html это можите легко проверить на своей системе, то же получается при очень малом буфере 4-8 семплов. легкодоступный оптимизатор алса Запустите еще один плеер с настройками джек и он вам споет параллельно. Тема муссировалась в европе и была откинута за отсутствие битовой точности Откуда вы это берёте ??? Jack - это самый продвинутый RT звуковой сервер. Jack по возможностям и кол-ву настроек это аналог ASIO драйвера профф. интерфейса. Я использую Jack чтобы полностью исключить влияние софт-плеера, коммутатор для работы с плагинами, плюс очень много различных полезных плюшек ... Про битпрефектность Jack - там полный порядок, иначе быть не может, это видно при работе в терминале. Прежде чем писать про недостатки сервера Jack, поинтересуйтесь кто его разработчик и где его используют, а чтобы понять и освоить все его возможности потребуется очень много времени

Чтобы понять что система ALSA (по умолчанию) очень далека от совершенства, установите OSS4.

Долго выбирал уши, выбрал такие http://en.goldenears.net/14529 ровный низ и середина ... http://en.goldenears.net/GR_Headphones здесь большая база АЧХ и прочего по наушникам.

Рад буду помочь, по своим возможностям, хоршая новость В Linux есть возможность настройки всего, даже драйверов на самом низком уровне т. к. есть исходники на все ...

А куда его подключают, разве не к компу. Это не USB карта ? Откуда берется цифра, каким плеером пользуетесь не софтовым ... Что такое USB ?? USB звуковая карта - подключена через USB интерфейс, PCI звуковая карта - через шину PCI

Понимаю так, что в первых CD был минимальный буфер т. е. все зависело от механики, ДСП минимально влиял на цифровой поток до ЦАП. С развитием технологий и удешевлением памяти буфер стал огромным, влияние механики стало минимальным. Но звук стал хуже, значит ДСП справляется со своей задачей хуже прицензионной механики. При выводе звука с PC похожая ситуация, минимальный буфер-задержка звук лучше, но этого сложно добиться. Максимальный буфер звук "тухлый". Пытаюсь разобраться в чем причина, вроде что-то проясняется http://forum.doctorh...200#entry933895 замеры с выхода ЗК частотомером Ч3-33, дают похожие результаты.