Как закрепить длину буфера записи в bass.dll?

Question

[Михаил]

Здравствуйте. Очень стараюсь найти решение моей проблемы с bass.dll.
Моя программа считывает звук с микрофона и обрабатывает его. Загвоздка в том, что до длина буфера, которым оперирует коллбек, не статична. Параметр length меняется: 5512, 11024, 8268, 8268, 8268, 11024, 8268...
Долго изучал справку, но так и не нашел как зафиксировать длину буфера.

Вот так происходит захват звука:

rchan = BASS_RecordStart(FREQ,CHANS,0,&DuffRecording,0);  // rchan - канал записи

коллбек:

BOOL CALLBACK DuffRecording(HRECORD hangle, const void *buffer, DWORD lenght, void *user)
  {
  if((reclen % BUFSTEP) + lenght >= BUFSTEP)  // динамическое выделение памяти под поток
     recbuf = (char *)realloc(recbuf,((reclen + lenght) / BUFSTEP + 1) * BUFSTEP);
  memcpy(recbuf+reclen,buffer,lenght);  // recbuf - массив данных
  reclen+=lenght;  // reclen - длина массива recbuf 
  return TRUE;
  }

Организация не самая лучшая. Буду исправлять многое в коллбеке. Но главное для меня сейчас - закрепить длину буфера. Вы имели дело с подобной проблемой?

Answer 1

[jcmvbkbc]

Типовое решение этой проблемы -- накапливать данные у себя и обрабатывать, когда накоплено столько, сколько нужно. Совсем тупая реализация на С:

char *buf;
size_t buf_sz;
...
BOOL CALLBACK DuffRecording(HRECORD hangle, const void *buffer, DWORD lenght, void *user)
{
  buf = realloc(buf, buf_sz + length);
  memcpy(buf + buf_sz, buffer, lenght);
  buf_sz += length;
  return TRUE;
}

// эту функцию нужно вызывать когда есть новые данные,
// например, после каждого вызова DuffRecording
void chunk_handler(void)
{
  size_t offset = 0;
  while (buf_sz >= offset + CHUNK_SIZE) {
    do_something_with_data(buf + offset);
    offset += CHUNK_SIZE;
  }
  if (offset) {
    memmove(buf, buf + offset, buf_sz - offset);
    buf_sz -= offset;
  }
}

// эта функция будет вызвана с p указывающим на буфер длиной CHUNK_SIZE
void do_something_with_data(void *p)
{
  ...
}

Comments

[Михаил]

Мне необходимо написать программу для потоковой обработки и фильтрации сигнала, а также одновременного вывода всех графиков на экран + автокорреляция. Реально ли с предложенным Вами подходом всё это надёжно организовать? Я стараюсь заложить в программу наиболее надежный фундамент :) . Например такой: s020.radikal.ru/i711/1502/96/3471cfc1495b.jpg Как относитесь к такому алгоритму?

[Михаил]

Пояснение к картинке:
1) Создание аккумуляционного кольцевого буфера заданной длины (кол-во кусков * размер буфера).
2) В этот буфер коллбеки складывают данные с микрофона.
3) Ожидается пока данные с микрофона заполнят хотя бы один буфер на вывод и запускается процесс отдачи из этого аккумуляционного буфера.

[Михаил]

Извините, я излишне много задаю вопросов. Главное что мне нужно знать, это позволит ли Ваш алгоритм реализовать мои задачи при должном подходе.

[jcmvbkbc]

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

[Михаил]

T - время обработки буфера и отправки на воспроизведение s42.radikal.ru/i095/1502/bc/5095af598c89.jpg

[jcmvbkbc]

Ну да, такая картинка мне понятна, T на ней должно быть <= Delay чтобы не икало.

[Михаил]

jcmvbkbc: Значит придется искать другой способ с фиксированным буфером. MCI, WASAPI.. в какую сторону лучше копать?

[jcmvbkbc]

> Значит придется искать другой способ
Я не понял, из чего это следует. Если величина задержки между записью и воспроизведением в ваших руках, можно поставить её такой, чтобы за её время набиралось сэмплов хотя бы на один период воспроизведения, а всё остальное хранить в буфере.

[Михаил]

jcmvbkbc: Просто про Real Time с приемлемой задержкой можно тогда забыть. Схемы обработки выйдут сложнее тех, что я выше привёл. Это шаманство для меня очень сложно. Буду копать в сторону фиксированного буфера) Спасибо!