Библиотека сайта rus-linux.net
Audacity
Глава 2 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Audacity,
глава из книги "The Architecture of Open Source Applications" том 1.
Автор: James Crook
Перевод: Н.Ромоданов
2.6. Блочные файлы BlockFile
Одна из проблем, с которыми сталкивается Audacity, это поддержка операций вставки и удаления в аудиозаписях, длина которых может составлять часы. Записи могут легко стать настолько длинными, что не будут помещаться в доступную оперативную память. Если аудиозапись находится в одном файле на диске, то вставка аудиофрагмента где-нибудь ближе к его началу может означать, что для того, чтобы освободить место для вставляемого фрагмента, потребуется перемещение большого количества данных. На копирование этих данных на диск потребуется много времени, что означает, что из-за этого Audacity не сможет быстро реагировать на простые изменения.
Решение этой проблемы в Audacity состоит в разделении аудиофайлов на большое количество блочных файлов BlockFile, размер каждого из которых может быть равным около 1 МБ. Это основная причина, почему в Audacity есть свой собственный формат звуковых файлов с мастер-файлом с расширением .aup. Это файл XML, с помощью которого координируется использование различные блоки. Изменения вблизи к началу длинной аудиозаписи повлияют только на один блок и на мастер-файл .aup.
В блочных файлах BlockFile соблюден баланс решения двух противоречащих друг-другу задач. Мы можем вставлять и удалять аудиозаписи без чрезмерного копирования, и во время воспроизведения мы при каждом запросе к диску гарантированно получаем достаточно большие куски аудиозаписей. Чем меньше размер блоков, тем потенциально больше требуется запросов к диску для выборки одного и того же количества звуковых данных; чем больше блоки, тем больше объем копирования при вставках и удалениях.
Внутри блочных файлов Audacity никогда нет неиспользуемого внутреннего пространства и они никогда не выходят за пределы максимального размера блока. Чтобы так было всегда, мы, когда вставляем или удаляем фрагменты записи, выполняем копирование по частям, равным размеру одного блока. Когда нам не нужен какой-нибудь блочный файл, то мы его удаляем. Ссылки на блочные файлы сохраняются, так что когда мы удаляем некоторый аудиофрагмент, информация об этом фрагменте будет присутствовать в блочных файлах, тем самым позволяя выполнять операции undo до тех, пока мы не сохраним результат. В блочных файлах Audacity никогда не нужен сборщик мусора для освобождения пространства, который нам бы потребовалось использовать в случае, если бы использовали подход «все в одном файле».
Объединение и разбиение больших кусков данных является основными действиями системы управления данными, начиная от B-деревьев в таблицах BigTable компании Google и заканчивая управлением развернутыми связанными списками. На рис.2.5 показано, что происходит в Audacity при удалении фрагмента аудиозаписи, который находится ближе к началу записи.
Рис.2.5: Перед удалением в файле .aup и в блок-файлах BlockFile хранится последовательность ABCDEFGHIJKLMNO. После удаления фрагмента FGHI два блок-файла BlockFile будут объединены в один
Блочные файлы используются не только для аудиозаписей. Есть также блочные файлы, в которых кэшируется обобщающая информация. Если в Audacity делается запрос отображать на экране запись длинною в четыре часа, то невозможно повторно обрабатывать всю аудиозапись каждый раз, когда происходит перерисовка экрана. Вместо этого используется обобщающая информация, в которой приведены максимальная и минимальная амплитуды аудиосигнала для всех фрагментов записи. Когда масштаб увеличивается, Audacity делает перерисовку с использованием фактических фрагментов записей. Когда масштаб уменьшается, Audacity делает перерисовку с использованием обобщающей информации.
Отличительная особенность системы блочных файлов BlockFile состоит в том, что блоки не обязательно должны быть файлами, созданными в Audacity. Они могут быть ссылками на подразделы аудио файлов, таких как временные промежутки аудиозаписей, хранящихся в формате .wav. Пользователь может создать проект Audacity, импортировать аудиозаписи из файла .wav и смикшировать их с несколькими, создав при этом только блочные файлы с обобщающей информацией. При этом сохраняется дисковое пространство и экономится время копирования аудиозаписей. Однако, все говорят, что это довольно плохое решение. Слишком многие из наших пользователей удаляют исходный аудиофайл .wav, думая, что полная его копия будет находится в папке проекта Audacity. Это не так, поэтому без оригинального файла .wav аудио проект больше воспроизвести не удастся. В настоящее время Audacity по умолчанию всегда копирует импортированную аудиозапись, создавая при этом новые блочные файлы BlockFile.
Решение с использованием блочных файлов вылилось в проблемы в системах Windows, где из-за большого количества блочных файлов сильно падала производительность. Это было связано с тем, что Windows, как оказалось, намного медленнее обрабатывала файлы, когда их много в одном и том же каталоге, что аналогично проблеме с замедлением работы при большом количестве виджетов. В более поздних вариантах было сделано так, что использовалась иерархия подкаталогов и в каждом каталоге никогда не было более сотни файлов.
Основная проблема со структурой блочных файлов связана с тем, что она открыта для конечных пользователей. Мы часто слышим от пользователей, что они переместили файл .aup и не поняли, что также должны были переместить папку, содержащую все блочные файлы. Было бы лучше, если проект Audacity представлял собой один файл, а Audacity взяла на себя ответственность за то, как использовать пространство внутри файла. Во всяком случае это привели бы к увеличению, а не к уменьшению производительности. Основное, что для этого нужно, это - сборщик мусора. Более простой подход состоит в копировании блоков в новый файл при его сохранении в том случае, если в файле не используется более чем некоторый заранее определенный процент памяти.
Продолжение статьи: Использование сценариев.