sound, SB, AC97 и другое

Drivers for sound cards
  • Видимо никому ничего не интересно в данном направлении. Ну что же, отрицательный результат - тоже результат. Возможно кто то, когда то, все же "наступит" на эти строки и хотя бы реально попробует. А между тем, на сегодня, существенные изменения в редакции 502(ac97_502.zip). Теперь это точно готовый тестовый этап кода.
  • У меня к сожалению, мертвый кодек AC97 на nforce2 (убил, когда злоупотреблял использованием его в качестве осциллографа) :). А так обязательно бы потестил... :)
  • В драйверном деле никакая "мелочь" не лишняя... поэтому твои данные тоже полезны мне(!), т.к. любопытно посмортеть что мать, мост, кодек тестятся, находятся, сопоставляются со справочником + номера функции, девайса как PCI, линия прерывания какова и та ли, что пишет биос на этапе загрузки.... TXT ЛОГ экрана, который генерит прожка, дала бы мне статистику и вообще еще один практический результат на месте...
    А ты видимо подпалил Вход/Выход перенебрегая некоторыми осторожностями? :) У каждого практикующего, свой счет подобных "побед" :) у меня свой конечно имеется ;))) А вот "паленость", думаю, до самого AC-LINK обмена кодека с чипом южного моста матери вряд ли добралась, посему лог картинка это может показать, как в прочем и то, что если скажем, в винде он есть и драйвер лепится, но не работает как звуковуха, то я прав. Но это мои рассуждения, тебе виднее, как там на самом деле.
  • Отправил тебе на мыло лог-файл. А насчет пренебрежения осторожностями, ты прав: видимо ткнул случайно щупом в цепи питания ипытуемого устройства :)
  • Serge
    Я тоже готов сотрудничать, только в инет выхожу редко, по этому наше сотрудничество будет в некоторой инерцией. Если у тебя есть доступ к FIDO, то можешь писать на 2:5066/160.25, так будет оперативнее с моей стороны.
    Как подфункции сделаны ММХ микшеры на 2, 3, 4 потока в 1. ММХ конвертеры моно 44.1 в стерео 44.1, стерео 22.05 в стерео 44.1, моно 22.05 в стерео 44.1 и примитивный ресемплер 44.1 в 48.0
    Но MMX есть не на всех х86 процах. Например, на старых 486 ноутах это недопустимо, но я говорю про подсистему а не про драйвер. По этому в подсистеме я не буду использовать MMX, по крайней мере пока.
    Когда заканчивается проигрывание очередного 16 кб сегмента АС97 генерирует прерывание
    и драйвер микширует в первичный буфер очередные 16 кб из звуковых буферов. Само микширование
    происходит блоками по 512 байт
    ...
    Недостаток - задержка с началом воспроизведения статического буфера.
    При 16 кб сегменте и частоте 44100 масимальная задержка будет приблизительно 0.185 с.
    если уменьшить размер сегмента до 8 или 4 кб задержка уменьшится до 0.092 и 0.046 с, что должно
    быть приемлемым.
    Этого недостатка можно избежать, если загружать (преобразовывать/микшировать) новую порцию звука после того, как запустил воспроизведение очередного блока (у тебя их 4 по 16 кб.). А вообще звуковые данные лучше измерять в выборках, а не в килобайтах.
    Для экономии памяти звук в буферах хранится в исходном формате и приводится к основному
    (стерео 44100 или 48000) перед микшированием также блоками по 256 или 512 байт.
    Ну, это сотря для какого количества процессов, а так же смотря какая частота звукового устройства, хотя я опять говорю только про подсистему.
    Для кратных частот 11025 -> 22050 -> 44100 это очень просто. Для преобразования дробных частот
    44100 -> 48000 лучше конвертировать сразу весь буфер, моно в моно, стерео в стерео.
    А у меня конвертирование будет в произвольную частоту. Особенно это пригодится для трекерной музыки, где тональность звучания задаётся изменением частоты дискретизации.

    если что, пиши на hater05<ухо>mail.ru
  • Но MMX есть не на всех х86 процах. Например, на старых 486 ноутах это недопустимо, но я говорю про подсистему а не про драйвер. По этому в подсистеме я не буду использовать MMX, по крайней мере пока.
    Я ориентировался на ММХ потому, что если на компе есть АС97 кодек то и процессор с ММХ тоже есть. Позже я хочу написать версии для SSE и SSE2. Версии для ALU тоже можно сделать.
    Этого недостатка можно избежать, если загружать (преобразовывать/микшировать) новую порцию звука после того, как запустил воспроизведение очередного блока (у тебя их 4 по 16 кб.). А вообще звуковые данные лучше измерять в выборках, а не в килобайтах.
    Небольщая задержка будет в любом случае. Когда программа посылает драйверу команду play_buffer звук уже смикширован и воспроизводится, значит его можно смикшировать только в сегмент следующий за текущим. Возможна ситуация когда начнется воспроизводится сегмент, в который мы только что начали микшировать звук и будет щелчок.
  • Serge,я вот всё думаю,что значит драйвер AC'97 будет ввиде отдельного модуля ?
    Всмысле он будет работать из Колибри как обычная программа ?
    А как тогда он будет обрабатывать запрос от нескольких программ ?
    Если обмен сообщениями с драйвером будет происходить через IPC, то понадобиться выделять физический блок памяти.
  • VaStaNi
    Сожалею, я не мог тебе ответить, так как болел гриппом целую неделю.
    Сейчас ссылка уже не работает, вероятно, ты удалил файл. Если выложишь снова, могу протестировать.

    andrew_programmer
    Скорее всего, он будет в виде подключаемого драйвера, хотя сама система звука будет встроена в ядро, без этого не обойтись.
    IPC тут совершенно не причем. Приложение через системную функцию передает звуковой подсистеме координаты расположения звукового блока, а дальше оно свободно. Правда может возникнуть необходимость контролировать окончание проигрывания или остановить проигрывание, так что время от времени приложение будет запрашивать у звуковой подсистемы данные о том, что делается.
  • Я про IPC сказал на тот случай,если драйвер будет ввиде программы.
  • Можно сделать драйвер в виде отдельной программы, но нужна функция для установки пользовательского обработчика прерывания. Пока такой функции в системе нет
  • Mario79 wrote:VaStaNi
    Сожалею, я не мог тебе ответить, так как болел гриппом целую неделю.
    Сейчас ссылка уже не работает, вероятно, ты удалил файл. Если выложишь снова, могу протестировать.
    Дык чуть ниже писал, что 502я теперь... т.е. глючное и старое удалил, оставил только более "уверенный" :) вариант + мелкая доводка.
    http://atom-os.narod.ru/edit_versions/ac97_502.zip
  • Пользовательское прерывание установить можно. Пример - программа PPP. Однако это реализовано в системе ужасно криво. Программа может получить сигнал о прерывании с опозданием более двух секунд (это зависит от количества процессов).
  • Иван Поддубный wrote:Пользовательское прерывание установить можно. Пример - программа PPP. Однако это реализовано в системе ужасно криво. Программа может получить сигнал о прерывании с опозданием более двух секунд (это зависит от количества процессов).
    Так в том то и оно, что криво и кто и когда это хотя бы НАЧНЕТ менять в системе!??? Для драйверов, именно для драйверов этот механизм что есть сейчас - не приемлем и надо менять ядро... Со стороны взглянуть - получается, что либо не хотят ребята, либо не видят зачем это нужно или не могут, но хуже всего, что просто молчание наблюдается! Т.е., как будто проблемы и нет. Не понимаю эту позицию. Лично я не раз говорил еще на старом форуме про эти вещи (IRQ,DMA,железо...), но это было столько раз, что я не хочу быть занудой (или перестал им быть)...
    На счет прерываний по сути и сейчас. Надо (так думаю) хотябы завести такое понятие, как резервирование системой некоторых прерываний, как ИМЕННО СИСТЕМНОЕ! Т.е. если уж известно или оттестировано, вычитано, что IRQ5, скажем не что иное, как AC97, то обработчик ставится системой в IDT именно на IRQ5 позицию и никакой "гад" не может запросить иного, т.к. считается, что система "лучше знает"! А поскольку у Вас все монолит и драйвер в одном кольце с ядерным кодом, то не вижу проблем вообще!
    Мало того! Обработчик НАДО ставить кака можно "прямее и короче", минуя тормоза, присущие вызову int 0x40, да собственно мышонок так, кажется по умолчанию то стоит (вкраплен). Вот те и реактивность работы драйвера.
    Имеющие уши - да услышат! :0)
  • Не надо ничего специально резервировать. Нужен массив куда можно будет записывать адрес пользовательского обработчика прерываний. Номер IRQ - индекс в массиве. Если сделать двумерный массив, можно будет установить несколько обработчиков на один IRQ и вызывать их последовательно.
    Системный обработчик должен считывать из массива адрес пользовательского обработчика и передавать на него управление.
  • Who is online

    Users browsing this forum: No registered users and 5 guests