AleXH

Юзкейс: Скачиваю альбом юТ с созданием папки в папке Download, отслушиваю в АП (винд), удаляю папку с альбомом (не понравился, если понравился - переношу на ПМЖ в Music), скачиваю новый альбом в Download, жму в АП на Open и открывается не папка Download, а Обзор папок (ХП), что не удобно. - Предлагаю пытаться открывать папки из бывшего пути по восходящей, т.е. откроется Download с новой раздачей.

У меня призрачная надежда на то, что если выбросить интерфейс, управлением им, настройку арс, парсинг ответов пользователя и тд., используя настройки из config.dat, path.txt, то возможно получится более благозвучный вариант. Понятно, что во время воспроизведения вышеназванный код не работает, но линукс и пс не дают гарантии однозначного звучания, звук "шатает" от сборки к сборке.

Игорь, планов на арс без интерфейса, только под комстроку, чтобы заюзать скриптом - нет?

Думаю здесь вопрос в другом - вот музыка в качестве, а АП её "не умеет". Другое дело стоит ли тратить время на добавление возможности её воспроизведения, тут вам виднее.

Почему fp64, а не fp32? — как я понимаю, поскольку мантисса у fp32 23 бита + бит знака, то и адресовать она может только 24 бита fixed без ошибок, выше придётся юзать экспоненту и здесь у нас начнутся ошибки округления до ближайшего возможного значения, передаваемого форматом, поэтому для передачи 32-х битных fixed значений нужно использовать fp64 с 52-х битной мантиссой. Если ошибаюсь — поправьте. имхо для раздачи конечно имело смысл преобразовать fp64=>32 fixed, размер был бы в 2 раза меньше при той же передаваемой информации.

Возможно стоит в интерфейсе на видном месте разместить надпись Help/Помощь по нажатии на которую будет открываться html с оглавлением с ссылками на разделы/якоря html-страницы.

Игорь, может в многострочном можно что-то оптимизировать/подкрутить и пересобрать? Может у нового билда будет звук лучше/ближе к офиц.

офиц этого не делает, а из-за того, что многострочный ощутимо уступает в звучании офиц, приходится использовать оба. Можно, конечно, скриптом добавлять LF, но теплится надежда на то, что новая версия будет звучать лучше ) У офиц полнокровные низ-бас-середина, многострочный же снизу с завалом (

Игорь, многострочный арс не понимает path.txt содержащий последнюю строку без LF.

Точно, забыл, спасибо.

Подтверждаю, спасибо. UP. Заметил отличие от поведения офиц - запуск беты не вытесняет из памяти офиц, играющую в это время.

Гуд 1. Пути читаются правильно, в том числе и содержащие кириллицу, иероглифы. 2. При замене path.txt после завершения воспроизведения текущего трека, воспроизводит следующий трек из нового path.txt. Не гуд 1. Воспроизведение path.txt начинается со 2-го трека, а не с 1-го. 2. Записывает closed в play.txt, вместо переименования его в stop.txt. Как вариант можно адресовать треки через inodes, если путь не может быть правильно представлен в UTF-8. Каждый вариант звучит по разному, пока наилучший (имхо) звук даёт офиц.

сейчас гляну - посмотрел, отыгрывает 1-ый трек, затем тишина, но в имени 1-го трека есть одинарные ascii кавычки ))) Во 2-ом есть обычные ascii круглые скобки. Рекодинга нет, выше есть path.txt, в нём видно, что только кавычки 2-х байтовые, остальное ascii, FAR открывает в редакторе как UTF-8, отображает корректно. Пути грабятся и составляются через слэш из $(ls -pL "$path") как есть, а поскольку разделы NTFS, то UTF-8. Завтра могу попробовать создать: /media/sdd2/test/1.wav /media/sdd2/test/2.wav /media/sdd2/test/3.wav и посмотреть,будут ли отыгрываться 2-ой и 3-й треки. Кстати, все пути к музфайлам замечательно передаются в качестве аргумента ap "$path", но не забываем отыгрывается-то только 1 файл, поэтому возможно проблема есть и в этом случае, просто до неё дело не доходит. UP. Проверил на тесте выше - без изменений, отыгрывает только 1 трек, затем тишина. Какими у стелс-ар должны быть права? У меня он создаёт devtmpfs, mode=0755 Проверил test с ascii <80h путями на 1-ой версии - весь плейлист отыгран, процесс ар завершён, но тест с юникодными кавычками провален.

это типографские, юникодные кавычки внутри пути. Чего только юзвери не суют в пути - юникодные кружочки, звёздочки - горе-дизайнеры. Это ещё на иероглифах не тестировал ;-)

Стартует со 2-го трека, а не с 1-го, после его проигрывания тишина, ар в памяти висит. Имхо вместо записи closed лучше переименовывать play.txt => stop.txt, тогда будет видно на каком треке остановился. Не догадался проверить нормально ли в интерфейсе треки отыгрывает, офиц отыгрывает, месяц назад слушал. UP. Подозреваю дело в UTF8 символах типографских кавычек.

path.txtБаг парсера. в папке 5 flac + 1 cue, пути длинные. Скриптом формирую path.txt, в нём оказываются 5 полных путей к флэкам, все строки завершаются LF, в том числе и последняя, 5-ая. запускаю ар в своей папке, ар формирует play.txt и завершается, в play.txt попадает 2 байта "6:".

Да, согласен, неразумно, в сад. Если запускать из комстроки поведение такое же - 1-ый трек и тишина, процесс ар висит в памяти, play.txt содержит 2:второй трек. В первой версии треки отыгрывались, но изменения path.txt не подхватывались. UP. Есть вопрос - убивая стелс ар с помощью killall ap убивается только процесс ар? - Он же в одну нить и ничего не порождает? - А как насчёт очистки использованной им памяти - всё на плечах сборщика мусора ядра? Как всё это организовано? - И Миша мне какую-то дичь втирал про демоническую природу стелс ар - это так?

в UP так и сделал, но 2-ой трек из path.txt - тишина, ар похоже просто висит в памяти. Но что любопытно, 2-ю строку в play.txt сохраняет, а вот со стартом её воспроизведения траблы - не из-за того же? - текущая папка не музфайла, а ар. Хотя пути к музфайлам могут быть произвольными.

Последний вариант похоже не видит path.txt и, возможно, своей папки /usr/ap, если запущен из скрипта, а не комстроки. в башскрипте: 1. создаю /usr/ap/path.txt с полными путями к *.wav файлам 2. линкую ар2 в ар 3. запускаю ар открывается интерфейс ар, вижу карта выбрана правильно, FM (в config.dat так), MMAP (в config.dat так), буфера default (в config.dat так), приоритеты сброшены в 0, должно быть 10 и -10, ядро не выбрано, должен быть singlecore. Ожидал запуск в стелс с воспроизведением. Ок, закрываю по х, попадаю в скрипт, выхожу из него, ls -l - я в папке /usr/ap, cмотрю path.txt - 745 байт, ар2 слинкован в ар, запускаю ар, воспроизводится 1-ый трек, затем тишина, ps показывает ар в памяти, содержание curr.txt верное - 2:вторая строка. Первый вариант треки из path.txt играл, один раз прочитать path.txt мог. заменил в ар curr.txt на play.txt (нативнее), на поведении ар никак не сказалось. UP. Разобрался - дело было не в бобине (частично) - скрипт изменяет текущую директорию, поэтому у ар сложности при старте-чтении конфига и тд. Лучше было бы чтобы ар смотрел из какой папки запущен процесс и использовал её как домашнюю для своих файлов. Добавил перед ар установку его папки - теперь стартует в стелс воспроизводя 1-й трек, 2-й попрежнему - тишина. Это уже на стороне ар.

Имхо лучше каждый раз читать построчно, отсчитывая строки считать следующую. Даже 1000 строка не вызовет ощутимой задержки, учитывая что path.txt лежит в рамфс. С другой стороны 20 треков это уже >1 часа прослушки, поэтому path.txt c >200 строк практически нереален. Как вариант (необязательно), номер воспроизводимой строки и её саму можно сбрасывать в перезаписываемый curr.txt, тогда будет понятно что ап воспроизводит. Например: 1:Track01.flac

Спасибо. UP. В процессе эксплуатации ар замечены следующие недостатки: 1. Офиц и ласт ар не всегда правильно загружают/применяют настройки из config.dat (приоритеты процесса, конфиг ядер), если содержимое path.txt вызывает ошибку при парсинге, а порой и при правильном path.txt, но если это 1-й запуск ар. Процесс первичной настройки ар сопровождается подавляемыми ошибками? 2. Офиц читает из path.txt не строку, а до конца файла (ожидаемо), не ожидаемо - странно усекая при этом path.txt и перезаписывая его - было 745 байт, 7 строк, стало 403 байта, 4.5 строки. Т.е. парсинг path.txt неустойчив. Правильно ли я понимаю алгоритм - по окончании воспроизведения трека инкрементируется номер строки (только его мы храним в памяти), и делается попытка прочитать строку с новым номером из перечитанного path.txt, если успешно - воспроизводим, если нет, то завершаем процесс? Т.е пользователь может добавлять в плейлист новые пути к музфайлам в процессе воспроизведения.

У себя часто наблюдаю проблемы инициализации ASIO у АП в XP, у фу такого не наблюдается, равно как и у AudioPlayer плага в FAR. Лечится перезапуском АП. Игорь, на всякий случай напомню про многострочный path.txt для линукс версии.

AIT жмёт в xz лучше чем в lzma на 5% и существенно быстрее. Уровень сжатия не регулируется, но можно жать cpio и внешними архиваторами с желаемой степенью сжатия, лишь бы ядро умело распаковывать. UP. Нужна статически собранная команда вывода текущего времени, date должна подойти.

Залил в корень. У меня несжатый gzip'ом initramfs7.1 звучит лучше, возможно разницу даёт рефреш памяти в зависимости от содержания ячеек - для сжатого образа использована дополнительная память для работы распаковщика и она после работы не обнулена. Для подтвержения гипотезы нужна тулза обнуляющая всю свободную память. Предлагаю на послушать сделать ядро 3.7.8 с поддержкой распаковки cpio.gz (уже умеет), cpio.xz, cpio.lzma. AIT упаковывает в xz, lzma через указание в config.ini, секция ramdisk, Type=CPIO,XZ, либо Type=CPIO,LZMA. CPIO можно не указывать, в него упаковывается всегда. Распаковывать тоже должен, но... не смог, поэтому исходник рамдиска нужно хранить.

не получилось, оставил прежний вариант с промежуточным сохранением в файл и последующим его чтением.