У меня есть приложение на c #, которое воспроизводит простые wav-файлы через directsound. С тестовыми данными, которые у меня были, код работал нормально. Однако, когда я использовал реальные данные, при создании вторичного буфера возникла очень бесполезная ошибка: «ArgumentException: значение не попадает в ожидаемый диапазон».
Тестовые файлы имели скорость передачи 512 кбит / с, размер аудиосэмпла 16 бит и частоту дискретизации 32 кГц. Новые wavs - 1152 кбит / с, 24 бит и 48 кГц соответственно. Как я могу получить DirectSound, чтобы справиться с этими большими значениями, или, если нет, как я могу программно определить эти значения, прежде чем пытаться воспроизвести файл?
это управляемый DirectX v9.00.1126, который я использую, и я включил несколько примеров кода ниже:
using DS = Microsoft.DirectX.DirectSound;
...
DS.Device device = new DS.Device();
device.SetCooperativeLevel(this, CooperativeLevel.Normal);
...
BufferDescription bufferDesc = new BufferDescription();
bufferDesc.ControlEffects = false;
...
try
{
SecondaryBuffer sound = new SecondaryBuffer(path, bufferDesc, device);
sound.Play(0, BufferPlayFlags.Default);
}
...
Дополнительная информация: реальные wav-файлы также не воспроизводятся в Windows Media Player, сообщая, что для воспроизведения файла необходим кодек, в то время как они хорошо воспроизводятся в winamp.
Дополнительная информация 2: Сравнивая байты рабочих тестовых данных и плохих реальных данных, я вижу, что после фрагмента RIFF у плохих данных есть блок "bext", о котором интернет сообщает мне, что это метаданные с расширением широковещательного звука, в то время как тестовые данные поступают прямо в блок fmt. В плохих данных есть / is / fmt-чанк, поэтому я не знаю, плохо ли он сформирован или загрузчики должны искать fmt-данные дальше. Я могу посмотреть, смогу ли я получить некоторую информацию об этом бэк-бэк-баге от людей, предоставляющих мне данные - если они смогут удалить их, мой код все еще может работать.