LINUX.ORG.RU

DMA буфер маловат....


0

0

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

Прцедура обработки достаточно массивная, поэтому решил
напрямую читать из буфера ДМА: пока обрабатываешь --
записывается... благодать...
С помощью  mmap() и SND_CTL_GETISPACE 
к DMA доступился....
только больше 64к в буфере не помещается...
можно ли как-то его руками задавать?
Или это ограничение железа? 
Или вообще не надо так извращаться, а можно всё 
сильно проще сделать?

ЗЫ пользуюсь стандартным OSS драйвером и MSS-совместимой
картой. Linux Mandrke 7.0RE

Заранее спасибо, 
Ростислав
anonymous

ну такой он маленький, по-моему это ограничение железа а оно, DMA, тебе сильно помогает? делал замеры для работы с ним и без него? поделись результатами?

anonymous
()

А оно под обычным юзером работает?
Я как-то в молодости для данной задачи напрямую порты пинал, так только под рутом работало.

Havoc ★★★★
()

Замеров не делал. Вся бодяга (см. выше) чтобы пока идёт оцифровка программа могла ещё что-то делать. read() программу тормозит, пока не считается сколько заказал... С юзером работает. См. примеры от 4Front. (Я оттуда все эти вызовы надёргал). Можно, конечно попробовать fork() + shared memory... (один прцесс читает, второй обрабатывает) Что по зтому поводу Гуру думают?

Может PCI-карту попробовать?

Вопрос вдогонку. Провёл сегодня серию тестов с генератором сигналов и осциллографом. Выяснил, что на моей карте (OPTi 82c931) сигнал перед АЦП проходит через дифференцирующую цепь с постоянной времени ~10мс и через фильтр. отсекающий всё, что выше Найквиста. Ухлопал около получаса. Можно ли где почитать доку по карточкам, где эти параметры указаны явно? (Хотелось бы иметь возможность цифровать без всй этой дребедени)

Всех благ,

Ростислав (roux@chat.ru)

anonymous
()
Ответ на: комментарий от anonymous

>Замеров не делал. Вся бодяга (см. выше) чтобы пока идёт оцифровка 
>программа могла ещё что-то делать. read() программу тормозит, пока
>не считается сколько заказал... 

  А ты nonblocking read не пробовал?

asd
()
Ответ на: комментарий от asd

> А ты nonblocking read не пробовал?

И как ты зто делать предлагаешь?

read() запустили, буфер ( те самые 64к или меньше) считали и дальше поехали? Проблема в том, что надо считать за раз ну хоть вдвое больше... (лучше в 10 раз)

anonymous
()
Ответ на: комментарий от anonymous

>> А ты nonblocking read не пробовал?

>И как ты зто делать предлагаешь?

>read() запустили, буфер ( те самые 64к или меньше) считали и дальше
>поехали? Проблема в том, что надо считать за раз ну хоть вдвое больше...
>(лучше в 10 раз)

  А... Понял, что ты хочешь. 
  Да, nonblocking io не поможет.

  Но тогда и два процесса ситуацию не исправят -- у тебя все-равно
  все в скорость read() упирается.

asd
()

по-моему нет никакой проблемы, по крайней мере если сделать
в несколько потоков и здоровенный fifo между ними. имхо не такие
напряженные потоки данных для современных процов, в конце концов
mp3 players как-то работают, при этом выполняя нехилую обработку
ввиде декодирования и при этом занимая <5% CPU.

44KHz * stereo *16bit == <200KB/sec... по-моему совсем небольшой
поток чтобы обрабатывать на лету.

тот anonymous, который про замеры спрашивал.

PS. запиши какой-нить буфер за несколько минут на диск и натрави
свою обработку на него, если обрабатывается меньше чем пишется,
значит, в первом приближении, все успеет и на лету :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.