PolarLight

Видимо Вы не совсем поняли мою реплику. Игорь Вам пояснил популярнее. В отличие от ОЗУ, рамдиск - это тоже диск, со всеми вытекающими из этого последствиями.Если Вас устраивает звучание с рамдиска, это замечательно. Я рассуждаю чисто с технической точки зрения. На мой взгляд это явное заблуждение, ни коим образом не объясняемое с технической точки зрения. Но опять хочу повториться, если такой вариант воспроизведения кому-то нравится, замечательно.

Полностью согласен. На мой взгляд, Вы затронули самую суть проблемы, использования рамдисков для целей звуковоспроизведения. Драйверы этих виртуальных дисков достаточно сложные и непрерывно выполняют свою основную функцию по поддержанию в рабочем состоянии раздела и его файловой системы, заданных при создании диска. И если при работе с данными дополнительные прерывания не столь критичны, то при работе с музыкальным потоком в режиме реального времени это уже может создавать определённые проблемы, так или иначе влияющие на звук. Используя рамдиск мы сами создаём в своей системе дополнительную "тяжёлую" прослойку в виде постоянно работающего стороннего драйвера. При том, что при использовании режима FM, за счёт предварительного декодирования мы получаем больший функционал, а используемый для хранения декодированного трека блок памяти обслуживается "родной" ОС не требуя к себе "дополнительного внимания". Оттого ИМХО сложно понять пользователей минималистичных ОС и плееров с одной стороны борющихся за RT своей системы и тут же нагружающих её подобными "тяжёлыми" приложениями.

Вы знаете, слушая в наушниках, я не замечаю принципиальной разницы, поэтому предпочитаю FM, как, на мой взгляд, более правильный, с технической точки зрения.

А кто Вам сказал, что я про Linux рассуждал???audioshock сказал: Уверен, Вам будет не сложно пояснить, как специалисту, чем воспроизведение файла с диска в режиме FM, отличается от воспроизведение файла из ramdisk_а в режиме DI? Коллеги рассуждали про разницу режимов воспроизведения FM и DI с RamDisk-а в принципе, без привязки к ОС.

Господа, пардон, что встреваю в ваш очень интересный и поучительный диалог, но не удержался и хочу внести свою реплику из многолетнего опыта эксплуатации RamDisk Plus от superspeed.com. Так вот, работая с этим программным диском постоянно замечал, что даже простое обращение к расположенным на нём данным вызывает кратковременную загрузку процессора в пределах нескольких процентов. И чем интенсивнее обращения к диску, тем сильнее загрузка процессора. Что в нашем случае ни как ни есть кошерно. Возможно другие RamDisk-и работают "спокойнее", но всё равно через свои драйверы, являющиеся дополнительным звеном на пути данных. Короче говоря - я за режим FM.

По возможности не отклоняться от темы ветки.

Раз Вы опередили меня, не буду экспериментровать. Как и предполагалось опыт подтвердил финальную фразу известного персонажа: Режим FM, в отличие от использования RAM диска, грузит в ОЗУ уже готовые для воспроизведения данные.

Согласен, действительно, самый простой, хоть и не самый корректный способ. Буду дома, проверю и предоставлю скрины в студию.

На днях смонтировал в Snakeoil второй HDD подключённый непосредственно к роутеру. Сам диск лежит на видном месте и его светодиод отчётливо виден. Так вот, при воспроизведении музыки с этого диска в режиме FM интенсивное обращение к диску действительно происходит первые несколько секунд, пока в терминале отображается загрузка, в дальнейшем, до конца трека, обращения к диску нет. В режиме DI кратковременные обращения к диску происходят в течение всего времени воспроизведения трека. Сижу смотрю на диск как зомби. Уважаемый ampir-nn, вероятно Ваша квалификация позволила Вам настроить используемую версию Linux на более агрессивное кэширование, но Snakeoil из коробки работает именно так, как я Вам описал. Помнится в начале 90-х, используя Norton Utilities мне тоже удавалось заставить работать наши программы в малюсеньком кэше DOS-6.22.

В Linux все грузится в оперативную память, ... обратились к файлам на HDD - и они уже в памяти ... Интересно девки пляшут. А в Windows, что не так разве? А зачем в таком случае FM и DI варианты воспроизведения в АПлеере для Linux? Ведь FM это тоже DI только с воспроизведением из ОЗУ. Я-то говорил за Win версию плеера. И всё равно не думаю, что например при прослушивании "тяжёлых" треков, 0,5-1 гигабайтный трек мгновенно качнётся по сети в ОЗУ Linux-a и лишь полностью загрузившись будет воспроизводиться. Для этого и существуют режимы Full Memory с полной предзагрузкой не гарантирующие Gapless mode. Всё остальное это подкачивание с диска в ОЗУ в процессе всего воспроизведения трека, хоть в Windows хоть в Linux. Согласен, после этого файл может остаться в ОЗУ если плеер не научен, за ненадобностью, выгружать его из памяти. Возможно Вы не совсем точно выразили свою мысль. Неужели вы думаете что ОС считывает данные с носителей побитно ??? В каком-то смысле побитно, внутри блоков. Иначе что бы мы получали.

В принципе как и у меня. Только у меня сразу весь трек грузится в ОЗУ с попутным декодированием в RAW (если ошибаюсь, пусть автор поправит) и уже потом начинается воспроизведение. P.S. Т.е. у Вас SATA порт в процессе задействован.

, скажу честно, для меня, заядлого пользователя АПлеера в режиме Full Memory с полной предзагрузкой, сложно понять Вашу с Созерцателем позицию ... А этот режим я использую потому что большая часть моей фонотеки именно в wav и оттого режим полной предзагрузки работает практически в Gapless mode не вызывая неудобств. У кого много музыки, вероятно удобнее хранить её на NAS, который в свою очередь, можно подключить как по сети, так и напрямую к источнику по USB. Моя коллекция помещается на 4ТБ внешний диск и я слушаю с него подключая к источнику по USB 3.0. Учитывая что автор планирует выпуск Linux версии плеера с рендерером подумываю о небольшом выделенном UPnP/DLNA сервере. Думаю, что в этом случае диски с музыкой будут стоять внутри данного сервера. Кстати, Вы так и не ответили, где хранится Ваша фонотека и как она подключена к источнику. Расскажите плиз, мне честно, очень интересно узнать, как организован данный момент у гуру.

Боже упаси, уважаемый BAMF. Я тоже только поделился своим мнением. @IgorA, Вам и остальным для сведения.Используя в качестве ОС Snakeoil сейчас столкнулся с ситуацией. Когда в Снейке по умолчанию был выбран плеер Squeezelite то не удавалось запустить АПлеер. Вернее плеер запускался, но просил выбрать карту вывода звука, и сразу вылетал при любом варианте выбора. Стоило вернуть в Снейке в качестве плеера по умолчанию MPD, как проблема с запуском АПлеера автоматически снялась. Похоже, что в Снейке Squeezelite каким-то образом блокирует на себя вывод звука. Полностью с Вами согласен. Недавно в известной соседней ветке я выкладывал скрин запуска на своём источнике LatencyMon, правда ещё под WinServer, но не суть. Так вот USB у меня был активнее всех остальных процессов, хотя и с относительно небольшим значением. Сижу слушаю АПлеер с сетевого диска, ИМХО очень здорово звучит, применительно к моему скромному сетапу.

Сообразил, спасибо. А музыку откуда забираете, как диск/NAS подключен? А Вы не задумывались над вопросом, что возможен брак/проблема с сетью на системной плате. Ваш симптом похож на наводку, которую Ethernet не должен пропускать. Я у себя сейчас специально подключил внешний диск к роутеру, смонтировал его в Snakeoil, закинул несколько знакомых альбомов и слушаю. Вы знаете, вполне пристойно, для моего нынешнего сетапа.

nemool, а какой вариант подключения Вы считаете самым правильным? На мой взгляд, сетевое подключение музыкальной коллекции является наиболее правильным решением, во всяком случае правильнее чем установка HDD внутрь источника. BAMF, уважаемый, а как в таком случае Вы планируете управлять выделенным источником установленном в стойке с аппаратурой? У Вас что, в настоящий момент источник не подключен к сети? Вы управляете источником мышкой и клавиатурой с подключенным монитором?

@AleXH, а для каких целей может понадобиться GUI на выделенном музыкальном сервере?

Под Snakeoil тоже здорово, думаю, как минимум, не хуже чем под Tiny! Друзья, всех с праздником, С ДНЁМ ПОБЕДЫ!!

Это путь к файлу regcopy.txt который Вам предлагают почитать самостоятельно. Не бойтесь, он совсем маленький!

Спасибо, обновился, по PCM проблема снялась. Осталась проблема с SACD, треки которого плеер воспроизводит замедленно, выдавая такие данные:Samplerate: 88200 Bits per sample: 32 ALSA period time: 5804 ms ALSA period size (frames): 256 ALSA buffer size (frames): 8192 Я могу как-то повлиять на эту ситуацию. Уж очень нравится плеер, даже в его текущем виде.

@IgorA, здравствуйте. В отсутствие в настоящее время усилителя, слушаю вторую версию АПлеера с подключёнными библиотеками на встроенном реалтеке. Настройки согласно Вашим рекомендациям. В качестве ОС актуальный Snakeoil. При прослушивании треков wav 24-192, после перехода на сл. трек получаю сильное заикание на сильно замедленном воспроизведении. Выручает только ручное переключение через N, в этом случае трек воспроизводится нормально, но до следующего перехода. wav 24-176 скорость воспроизведения завышена. После перехода на сл. трек, такое же заикание как и у 24-192. wav 24-96 скорость воспроизведения экстремально высокая. После перехода на сл. трек, такое же заикание как и у 24-192. Только скорость воспроизведения с заиканием чуть выше. wav 24-88,2 и 16-44,1 всё нормально. Вот что значит встроенный реалтек. Но, объективности ради хочу заметить, что родной плеер Snakeoil-а MPD (dsd-rt) воспроизводит все эти форматы корректно.

А на мой взгляд кабель в этой ситуации вторичен. От него мало что зависит, если он не слишком длинный и удовлетворяет спецификации. Считаю, что первичны USB контроллеры стоящие на выходе из источника и на входе ЦАПа. А кабель, кабель должен быть покороче и серебряный.

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

Приурочив свой вопрос к празднику светлой Пасхи, в душе я надеялся, что автор даст именно такой ответ.Удачи Вам и Огромного творческого вдохновения! Очень ждём!!

@IgorA, здравствуйте! После крайне успешной версии Album Player Mini 2.110 с рендерером и одновременной миграции пользователей на Linux-сборки закралась сакральная мысль, но долго не решался задать не скромный вопрос. Вы не планируете выпустить давно обещанный Album Player 3.0 Mini но для Linux? Либо каким-то образом адаптировать существующую версию с имеющимися на рынке аудио сборками Linux. Управление по сети через внешний GUI прекрасно зарекомендовало себя, Чем в таком случае Album Player хуже того же набирающего популярность SNAKEOIL или ветеранов отрасли TinyMPD и иже с ним? Общественность затаила дыхание ...!!

Не, не надо изменений! Плеер в текущих версиях практически идеален по функционалу и работоспособности. Есть всё, что нужно и даже больше. А лучшее, враг хорошего.