Board.KolibriOS.org

У меня есть некоторые наработки по АС 97 и я бы хотел сделать драйвер для Колибри.
Но мне нужна помощь от разработчиков ядра, чтобы выяснить некоторые вопросы.
Например нужно выделить отдельную сис. функцию для работы со звуком,
выделить памаять в ядре системы (мин 64 кб) и т.д.

С кем мне связаться ?

Serge

Отдельна системная функция для работы со звуком уже имеется- это 55.Там уже выделяется память под звуковой буфер(поройся в исходниках).Ты пока делай изменения,которые тебе необходимы,а потом говори о них на форуме- обсудим.


А если ты и в правду хочеш написать драйвер,то ОЧЕНЬ хорошо.

Serge
mario79[dog]bk[dot]ru
обсудим

Хорошо. У меня еще вопрос.
Я могу установить свой обработчик прерываения, усли делать драйвер не монолитным с ядром а отдельным модулем?
У меня ICH5. на Интелловских чипсетах прерывание от АС97 можно завести на 8259 ( в моей системе IRQ10)
Сделал на пробу код под Дос с обработкой прерываний прогонял 300 Мб wаv через потоковый буфер 64 кБ
все работает на ура.

Serge
В принципе если сделать отдельным модулем это будет лучше, так как потом его можно доделывать отдельно от ядра.
Но возникают другие вопросы:
1) как подрубать драйвер - ведь единой концепции драйверов мы так и не выработали (и даже не пытались пока);
2) на какое прерывание его лучше вешать, в принципе свободные есть: 5, 9, 11 - остальные лучше не занимать, так как все равно на них придется вешать стандартные устройства со временем, когда будут переписывать код обработчиков, а 10 у нас видеоконтроллер стандартно. Хотя при желании можно повесить, только я не знаю пока, как на одно прерывание вешаются несколько устройств.
Также мне интересно как ты реализовал выбор частоты квантования? Или у тебя драйвер поддерживает только один чипсет, и ты ориентировался исключительно на него?

Пусть лучше БИОС решает, на какое прерывание вешать устройство. Номер прерывания можно прочитать через соответствующий регистр PCI.

Для переназначения обработчика прерывания можно написать процедуру, пока таковой нет.

Что касается памяти, то есть малодокументированные функции Allocate_Physical_Block и Free_Physical_Block в файле core/physmem.inc. Они предназначены исключительно для таких вещей, как буферы DMA и тому подобных.
Может быть, Халявин объяснит подробнее.

Я так и делаю. У меня на ICH5 получается irq10 но надо проверять на каждой плате так как биос может направить
его и на irq3, irq4, irq12 (:

Иван Поддубный
Может я и ошибаюсь, но мне казалось после перехода в PM процессора все прерывания надо заново устанавливать?
И тут уже BIOS совсем не причем.

Таблицу прерываний устанавливать конечно надо. Но в Интелловских ICH АС97 назначено PCIRQB# то есть по умолчанию он использует прерывания шины PCI и доступен только через APIC. В чипсете есть несколько регистров, которые позволяют перевести прерывания PCI на irq линии 8259 (rerout).
Биос выбирае одну из свободных линий, программирует чипсет и записывает номер линии в адресное пространство PCI (0x3C - по умолчанию там 0)
Если БИОС этого сама не делает или чипсет не позволяет то прерывания от AC97 можно обработать только через APIC

Разрабатывая драйвер для COVOX'а, я пришёл к выводу, что не хватает звуковой подсистемы, которая бы могла принимать звук с разных процессов и обращаться к драйверу звуковой карты. Т.е., она должна служить связующим звеном между драйвером и процессами, а так же добавлять функциональности при ограниченных ресурсах. Кое-что уже готово, но есть ряд вопросов.
1. Насколько я понял, современные звуковые карты имеют возможность воспроизводить одновременно множество дорожек, и каждый звуковой слот можно запрограммировать на собственный буфер, т.е. буфер для левого “уха” в одном месте, а для правого в другом, и таких буферов может быть много. Правильны ли мои рассуждения, или всё гонится через один буфер последовательно?
2. Если мои рассуждения в первом вопросе верны, то есть ли возможность запрограммировать каждый слот на воспроизведение с собственной частотой дискретизации, или они все работают только с одной частотой?

Hater
1) Если включен режим 5.1 то, наверное, так как ты описываешь, а в простейшем варианте все через один буфер. В реальном времени идет наложение звуков от нескольких источников (приложений), в этот момент уже обработанный буфер воспроизводиться. Когда он заканчивается, то на воспроизведение отправляется тот, который до этого обрабатывался, а этот идет в обработку. Это простейшая схема, но буферов может быть и больше, для обеспечения качества звука.
Но в любом случае в существующих моделях одновременно воспроизводится только один буфер. Конечно, если не включен режим пространственного звука 5.1, тут уже я точно не знаю.
2) Необходим многоуровневый конвейер для преобразования всего в одну выходную частоту квантования. Большинство кодеков АС97 вообще не позволяют менять выходную частоту (48000) или программируются нестандартно (не по доке INTEL). И уж они точно не могут в реальном времени поддерживать несколько частот квантования. Ведь по сути AC97 это всего на всего единичный ЦАП преобразователь. Впрочем, возможно самые дорогие звуковухи и имеют на своем борту несколько ЦАП, но стандартно только один.

В АС97 многоканальный звук воспроизводится через один буфер с чередованием сэмплов. Сначала идет 1 канал левый, правый, потом 2 канал, левый правый и т.д. На практике программа создает разные звуковые буфера в разном формате, а драйвер конвертирует их в рабочий формат и микширует в реальном времени.

Мне, видимо, всё равно придётся делать и поддержку многобуферного воспроизведения, и поддержку последовательных буферов. Например при прослушивании стерео звука на моём Crystal’е со стандартным драйвером, звук шёл только в одно ухо, в другом был только шум. Позже я прочитал в какой-то доке по саундбластерам, что в версии Pro 2 используются две страницы по 64 кб. , по одной на канал.

Сам я использую C-media и по ней у меня никаких доков пока нет, а многие мои знакомые музыканты вообще используют различную экзотику, например Aureal. Так что одним драйвером тут не отделаешся. Но это не повод чтобы ждать пока выйдет в свет моя подсистема, драйвер для AC97 нужен уже сейчас, и именно в виде отдельного модуля, хотя бы для того, чтобы разработать определённые методы подключения таких модулей.

Что касается т.н. многоуровневого конвейера и преобразования звука под определённую частоту, то это уже готово, правда пока всё разбросано по тетрадке в виде маленьких кусков кода.
Да, чуть не забыл. Вы рассматриваете цикл воспроизведения для AC97 который больше подходит для воспроизведения статичного (фонового) звука, и забываете о микшировании динамичных звуков (выстрелы, удары), я и это стараюсь предусмотреть. Звук будет воспроизводиться небольшими порциями, длина которых рассчитывается следующим образом.
Например:
мы загружаем в первом процессе 10 кб звуковых данных
во втором процессе 15 кб
в третьем 25 кб
у нас получается такая схематическая таблица
0000000000
000000000000000
0000000000000000000000000
Берётся ближайший конец загруженного блока и до него воспроизводится, а по окончании воспроизведения если не был дозагружен новый блок, можно организовать что-то вроде виртуального прерывания для обращения к заранее подготовленной программе в процессе, или просто информация об этом виртуальном канале удаляется из таблицы. Следующий блок воспроизведения будет опять, до ближайшего окончания загруженных блоков, в нашем случае 15-10=5 кб. А максимальный размер воспроизводимых блоков можно ограничивать, чтобы не потерять звуковую динамику.
В своей подсистеме, я стараюсь предусмотреть все основные манипуляции со звуковыми данными, так что, когда она будет готова, то подключаемые к ней драйвера будут состоять из таблицы характеристик звукового устройства и модулей: инициализации, воспроизведения, сброса.

Hater
Будет очень хорошо, если ты проработаешь и реализуешь эту систему.
А может тебе и Serge стоит объединить усилия?
Просто разделили бы между собой разработку отдельных модулей, глядишь быстрей закончили бы.

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

Как подфункции сделаны ММХ микшеры на 2, 3, 4 потока в 1. ММХ конвертеры моно 44.1 в стерео 44.1, стерео 22.05 в стерео 44.1, моно 22.05 в стерео 44.1 и примитивный ресемплер 44.1 в 48.0

Сейчас отлаживаю код под ДОС.

Hater



Я использую похожую схему. Только у меня первичный буфер состоит из 4 сегментов по 16 кб.
Потоковые (динамические) буферы должны иметь фиксированный размер, кратный размеру сегмента например 64 или 128 кБ.
При достижении середины и конца потокового буфера драйвер посылает программе, создавшей буфер
уведомление.
Статические буферы могут быть любого размера, драйвер будет округлять его до N * 512 байт, а неиспользуемый хвост дотирать нулями.

Когда заканчивается проигрывание очередного 16 кб сегмента АС97 генерирует прерывание
и драйвер микширует в первичный буфер очередные 16 кб из звуковых буферов. Само микширование
происходит блоками по 512 байт - так меньше забивается кеш 1 уровня. Я проверял блоки по 256 и 512 байт в VTUNE на моем P4 2.6c блоки по 512 байт оказались быстрее, но можно для разных процессоров сделать разные схемы.
Для экономии памяти звук в буферах хранится в исходном формате и приводится к основному
(стерео 44100 или 48000) перед микшированием также блоками по 256 или 512 байт.
Для кратных частот 11025 -> 22050 -> 44100 это очень просто. Для преобразования дробных частот
44100 -> 48000 лучше конвертировать сразу весь буфер, моно в моно, стерео в стерео.

При такой схеме нам не нужно манипулировать с BDL и постоянно менять длину воспроизводимого
блока. Недостаток - задержка с началом воспроизведения статического буфера.
При 16 кб сегменте и частоте 44100 масимальная задержка будет приблизительно 0.185 с.
если уменьшить размер сегмента до 8 или 4 кб задержка уменьшится до 0.092 и 0.046 с, что должно
быть приемлемым.

Если есть желание пиши на infinity_sound<собака>mail.ru