Board.KolibriOS.org

Serge тебе намылил ответ кратенько пока, смотри.
Всем! Всем! Всем!
Желающим хоть чем нибудь помочь упрямому фанатику-дровосеку прошу потестить и прислать отчетики и возможные баги по ДОС плееру на AC97 кодеках(несколько десятков наименований) и различных платформ южного моста VIA и Intel(ICH)
http://atom-os.narod.ru/edit_versions/ac97_501.zip
там есть README что, как, чем...

Видимо никому ничего не интересно в данном направлении. Ну что же, отрицательный результат - тоже результат. Возможно кто то, когда то, все же "наступит" на эти строки и хотя бы реально попробует. А между тем, на сегодня, существенные изменения в редакции 502(ac97_502.zip). Теперь это точно готовый тестовый этап кода.

У меня к сожалению, мертвый кодек AC97 на nforce2 (убил, когда злоупотреблял использованием его в качестве осциллографа) . А так обязательно бы потестил...

В драйверном деле никакая "мелочь" не лишняя... поэтому твои данные тоже полезны мне(!), т.к. любопытно посмортеть что мать, мост, кодек тестятся, находятся, сопоставляются со справочником + номера функции, девайса как PCI, линия прерывания какова и та ли, что пишет биос на этапе загрузки.... TXT ЛОГ экрана, который генерит прожка, дала бы мне статистику и вообще еще один практический результат на месте...
А ты видимо подпалил Вход/Выход перенебрегая некоторыми осторожностями? У каждого практикующего, свой счет подобных "побед" у меня свой конечно имеется )) А вот "паленость", думаю, до самого AC-LINK обмена кодека с чипом южного моста матери вряд ли добралась, посему лог картинка это может показать, как в прочем и то, что если скажем, в винде он есть и драйвер лепится, но не работает как звуковуха, то я прав. Но это мои рассуждения, тебе виднее, как там на самом деле.

Отправил тебе на мыло лог-файл. А насчет пренебрежения осторожностями, ты прав: видимо ткнул случайно щупом в цепи питания ипытуемого устройства

Serge
Я тоже готов сотрудничать, только в инет выхожу редко, по этому наше сотрудничество будет в некоторой инерцией. Если у тебя есть доступ к FIDO, то можешь писать на 2:5066/160.25, так будет оперативнее с моей стороны.


Но MMX есть не на всех х86 процах. Например, на старых 486 ноутах это недопустимо, но я говорю про подсистему а не про драйвер. По этому в подсистеме я не буду использовать MMX, по крайней мере пока.

Этого недостатка можно избежать, если загружать (преобразовывать/микшировать) новую порцию звука после того, как запустил воспроизведение очередного блока (у тебя их 4 по 16 кб.). А вообще звуковые данные лучше измерять в выборках, а не в килобайтах.

Ну, это сотря для какого количества процессов, а так же смотря какая частота звукового устройства, хотя я опять говорю только про подсистему.

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

если что, пиши на hater05<ухо>mail.ru

Я ориентировался на ММХ потому, что если на компе есть АС97 кодек то и процессор с ММХ тоже есть. Позже я хочу написать версии для SSE и SSE2. Версии для ALU тоже можно сделать.



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

Serge,я вот всё думаю,что значит драйвер AC'97 будет ввиде отдельного модуля ?
Всмысле он будет работать из Колибри как обычная программа ?
А как тогда он будет обрабатывать запрос от нескольких программ ?
Если обмен сообщениями с драйвером будет происходить через IPC, то понадобиться выделять физический блок памяти.

VaStaNi
Сожалею, я не мог тебе ответить, так как болел гриппом целую неделю.
Сейчас ссылка уже не работает, вероятно, ты удалил файл. Если выложишь снова, могу протестировать.

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

Я про IPC сказал на тот случай,если драйвер будет ввиде программы.

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

Дык чуть ниже писал, что 502я теперь... т.е. глючное и старое удалил, оставил только более "уверенный" вариант + мелкая доводка.
http://atom-os.narod.ru/edit_versions/ac97_502.zip

Пользовательское прерывание установить можно. Пример - программа PPP. Однако это реализовано в системе ужасно криво. Программа может получить сигнал о прерывании с опозданием более двух секунд (это зависит от количества процессов).

Так в том то и оно, что криво и кто и когда это хотя бы НАЧНЕТ менять в системе!??? Для драйверов, именно для драйверов этот механизм что есть сейчас - не приемлем и надо менять ядро... Со стороны взглянуть - получается, что либо не хотят ребята, либо не видят зачем это нужно или не могут, но хуже всего, что просто молчание наблюдается! Т.е., как будто проблемы и нет. Не понимаю эту позицию. Лично я не раз говорил еще на старом форуме про эти вещи (IRQ,DMA,железо...), но это было столько раз, что я не хочу быть занудой (или перестал им быть)...
На счет прерываний по сути и сейчас. Надо (так думаю) хотябы завести такое понятие, как резервирование системой некоторых прерываний, как ИМЕННО СИСТЕМНОЕ! Т.е. если уж известно или оттестировано, вычитано, что IRQ5, скажем не что иное, как AC97, то обработчик ставится системой в IDT именно на IRQ5 позицию и никакой "гад" не может запросить иного, т.к. считается, что система "лучше знает"! А поскольку у Вас все монолит и драйвер в одном кольце с ядерным кодом, то не вижу проблем вообще!
Мало того! Обработчик НАДО ставить кака можно "прямее и короче", минуя тормоза, присущие вызову int 0x40, да собственно мышонок так, кажется по умолчанию то стоит (вкраплен). Вот те и реактивность работы драйвера.
Имеющие уши - да услышат! :0)

Не надо ничего специально резервировать. Нужен массив куда можно будет записывать адрес пользовательского обработчика прерываний. Номер IRQ - индекс в массиве. Если сделать двумерный массив, можно будет установить несколько обработчиков на один IRQ и вызывать их последовательно.
Системный обработчик должен считывать из массива адрес пользовательского обработчика и передавать на него управление.