DirectSound. Проблема с записью длительного звукового потока .

← →
MACTEP'oK (2005-05-22 13:45) [0]

Почему при извлечении данных из буффера захвата (Lock -> UnLock) запись в буффер не происходит (тока позиция курсора записи изменяется). Это сильно заметно, если извлекать данные слишком часто (в меньшем объеме). Поскольку я записываю длительный звуковой поток действия извлечения и записи данных должны происходить одновременно. Но при этом я теряю данные которые должны были быть записаны в промежуток времени (Lock -> UnLock). Кроме того на этом участке остаются старые записанные данные, что вызывает крихтение и дребезжание.

Уважаемые мастера помогите решить эту задачу: Как записать длительный звуковой поток без потери данных?

← →
XProger © (2005-05-22 14:21) [1]

Может плохо тебя понял...
1) Выделяй память под буффер динамически по мере надобности
2) Чисти тот временный буффер перед записью нового куска

← →
XProger © (2005-05-22 14:25) [2]

Ах да...
Не пробовал поочерёдно менять буфера?
т.е. в этот пишется с этого считывается, потом swap и наоборот

← →
MACTEP'oK (2005-05-22 14:38) [3]

>>XProger © (22.05.05 14:21) [1]
>>2) Чисти тот временный буффер перед записью нового куска
Зачем пустота мне тоже не нужна
>>XProger © (22.05.05 14:25) [2]
>>Ах да...
>>Не пробовал поочерёдно менять буфера?
>>т.е. в этот пишется с этого считывается, потом swap и наоборот
И как же так их синхронизировать, чтоб ни одного "бита" даннх не потерять

← →
MACTEP'oK (2005-05-22 14:43) [4]

>>XProger © (22.05.05 14:25) [2]
>>Ах да...
>>Не пробовал поочерёдно менять буфера?
>>т.е. в этот пишется с этого считывается, потом swap и наоборот
(функции запуска и извлечения позиции записи занимают кое-какое время, за это время можно чтото потерять) Я бы хотел создать чо нибудь идеальное.

← →
MACTEP'oK (2005-05-22 14:53) [5]

Да! Самое главное! Из документации:
"Для каждого устройства воспроизведения можно создать не более одного буффера захвата"
http://www.compdoc.ru/prog/cpp/directs/
->Программирование в DirectSound
->Интерфейс IDirectSoundCaptureBuffer

← →
XProger © (2005-05-22 15:27) [6]

MACTEP"oK, попробуй обходиться более мелким буфером под данные, тем самым участив (Lock -> UnLock) :)
Если будет слышен треск или что-то в этом роде попробуй изменить формат данных (в худшую сторону для качества)

← →
MACTEP'oK (2005-05-22 15:45) [7]

>>XProger © (22.05.05 15:27) [6]
есть более эффективный способ: не уменьшать, а увеличить размер обновляемого(чтение буффера) участка - треска не будет. Но записаны будут всё равно не все данные, хоть и недозаписаных данных будет меньше. А в твоём случае ничего не получится - треск останется, и потеряных данных будет больше, да ещё и разбросаны они будут по всему буфферу.
А моя задача - записать звуковые данные любого формата Без Потерь.

← →
XProger © (2005-05-22 16:37) [8]

MACTEP"oK, а разве от размера буфера не зависит время доступа к нему при локании? ;)

← →
MACTEP'oK (2005-05-22 16:46) [9]

>>XProger © (22.05.05 16:37) [8]
move(pointer1,pointer2,DATASize);
и
for n:=0 to 100000 do
move(pointer(Cardinal(pointer1)+n),pointer(Cardinal(pointer1)+n),DATASize/100000);

чо быстрее

← →
XProger © (2005-05-22 17:06) [10]

Ты меня не понял...

← →
MACTEP'oK (2005-05-22 17:14) [11]

>>XProger © (22.05.05 16:37) [8]
Интересно почему же должно зависеть

← →
MACTEP'oK (2005-05-22 17:17) [12]

>>XProger © (22.05.05 16:37) [8]
Такая зависимость будет наблюдаться если буфер расоложен в памяти адаптера:
http://www.compdoc.ru/prog/cpp/directs/
->Программирование в DirectSound
->Интерфейс IDirectSoundBuffer
->Lock - запрос обновления данных в буфере
(последний абзац)

← →
MACTEP'oK (2005-05-22 17:18) [13]

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

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

← →
XProger © (2005-05-22 18:46) [14]

"подсистема вынуждена создавать временный буфер в основной памяти"
От размера буфера скорость выделения памати под него не зависит? ;)

← →
MACTEP'oK © (2005-05-22 21:01) [15]

>>XProger © (22.05.05 18:46) [14]
Но ведь у меня не аппаратный буфер, и расположен он в ОЗУ

Буфер захвата является первичным, а вторичные создавать нельзя.
Со вторичными буферами таких проблем не было.
Буфер захвата хоть и является первичным, но нигде не сказано, что он должен располагаться исключительно в памяти адаптера.

Ты снова меня понимать не хочешь...

>>XProger © (22.05.05 18:46) [14]
Нет я правильно понял: ты явно намекаешь на то, что мой буфер находится в памяти адаптера, и по этому при извлечении данных "подсистема вынуждена создавать временный буфер в основной памяти". А я говорю, что мой буфер находится в ОЗУ и....вообще скорость доступа тут не при чем. DirectSound просто обязан продолжать запись даже когда я читаю данные из участка буфера не пересекающегося с текущим участком записи. Но DirectSound в этот самый участок ничо не пишет. Тут уже встаёт вопрос: а использовать ли вообще для записи звука DirectSound, есть и другие средства.

У тебя время доступа к буфферу свыше 0.5 мс? Иначе нормальный человек ничерта не заметит...

Я ещё раз всё проверил, оказывается всё дело не в функциях Lock, UnLock, их вообще можно запускать только один раз чоб узнать pointer буфера в ОЗУ. Запись прекращается на время вызова процедуры(моей) извлечения данных, но там нет ничего особенного кроме функции move, но как такая функция может препятствовать процессу записи:
вот процедура Move
procedure Move( const Source; var Dest; count : Integer ); {$IFDEF PUREPASCAL} var S, D: PChar; I: Integer; begin S := PChar(@Source); D := PChar(@Dest); if S = D then Exit; if Cardinal(D) > Cardinal(S) then for I := count-1 downto 0 do D[I] := S[I] else for I := 0 to count-1 do D[I] := S[I]; end; {$ELSE} asm { ->EAX Pointer to source } { EDX Pointer to destination } { ECX Count } PUSH ESI PUSH EDI MOV ESI,EAX MOV EDI,EDX MOV EAX,ECX CMP EDI,ESI JA @@down JE @@exit SAR ECX,2 { copy count DIV 4 dwords } JS @@exit REP MOVSD MOV ECX,EAX AND ECX,03H REP MOVSB { copy count MOD 4 bytes } JMP @@exit @@down: LEA ESI,[ESI+ECX-4] { point ESI to last dword of source } LEA EDI,[EDI+ECX-4] { point EDI to last dword of dest } SAR ECX,2 { copy count DIV 4 dwords } JS @@exit STD REP MOVSD MOV ECX,EAX AND ECX,03H { copy count MOD 4 bytes } ADD ESI,4-1 { point to last byte of rest } ADD EDI,4-1 REP MOVSB CLD @@exit: POP EDI POP ESI end; {$ENDIF}

"как такая функция может препятствовать процессу записи"
Тормозить всю систему из-за большого кол-ва копируемых данных ;)

Она не может тормозить систему по следующим причинам:
1) Копируемых данных совсем немного.(~11000 Байт)
2) Такую системы как у меня даже мелкий софт не не смогёт затормозить.
Мне кажется, что DSound не хотит одновременно писать и читать из буфера, не смотря на то, что пишет и читает он из разных частей буфера. Х. знат чо.

DirectSound. Проблема с записью длительного звукового потока . Найти похожие ветки