Страсти по Саунд Бластер :)

Natrio
Задержки в канале воспроизведения никак не влияют на качество звука
Вы ошибатесь в понимании самого принципа работы этого самого “канала воспроизведения”. Звук всегда очень жестко привязан ко времени. Если бы задержки были всегда равны строго определенной величине с минимальной (микроскопической) погрешностью, то они действительно не влияли бы на качество прослушивания. Но это не так. В результате чего часть звуковой составляющей, в обычном случае, просто не доносится до слушателя, детализация звука теряется, он становится смазанным. Так вот для того, чтобы стабилизировать задержки используется rt ядро, а для того, чтобы уменьшить их используется jack в Linux (в Windows Asio).
yura_n
Если бы задержки были всегда равны строго определенной величине с минимальной (микроскопической) погрешностью, то они действительно не влияли бы на качество прослушивания. Но это не так. В результате чего часть звуковой составляющей, в обычном случае, просто не доносится до слушателя, детализация звука теряется, он становится смазанным.
Хорошая теория, логичная :)
Так БЫЛО БЫ, если БЫ звук генерировался ПРОГРАММНО, то есть не звуковой картой, а непосредственно процессором.

Однажды мне довелось программировать на ассемблере воспроизведение звука из файла под DOS с помощью 386 процессора и звуковой карты, и я могу описать, как это было сделано:
Был файл на винчестере, который средствами DOS по частям копировался в буфер в памяти, разделённый на две половинки.
1) После заполнения половинки буфера программа настраивала звуковую карту, и через DMA (прямой доступ к памяти) начинала забирать данные из буфера в памяти в свой буфер, и воспроизводить со своей, строго заданной тактовой частотой, то есть аппаратно, безо всякого участия процессора.
2) Тем временем программа заполняет вторую половинку.
3) Когда звуковая карта заканчивала чтение из первой половинки буфера (но до окончания воспроизведения), она посылала процессору заранее запланированное IRQ (аппаратное прерывание), которое вызывало внеочередное выполнение процессором функции-обработчика, который настраивал звуковую карту на воспроизведение второй половинки буфера в памяти.
4) Тем временем программа продолжала чтение из файла, опять в первую половину буфера.
и так далее.

Таким образом, уже на достаточно древнем компьютере была железная возможность воспроизводить звук НЕПРЕРЫВНО, поскольку делается это средствами аудиокарты. Программе остаётся лишь в срок успевать заполнять буфер, в воспроизведении звука она не участвует.

Как видите, здесь имеет место задержка между программным помещением звуковых данных в буфер, и их аппаратным воспроизведением. Эта задержка действительно не совсем постоянна – программа может работать неравномерно, а вот звуковая карта обязана воспроизводить звук строго с заданной тактовой частотой, например 44100Гц, что она и делает. Вот для того и предназначен буфер – ценой задержки в буфере давать возможность звуковой карте выдавать непрерывный звук.
Natrio
Так БЫЛО БЫ, если БЫ звук генерировался ПРОГРАММНО, то есть не звуковой картой, а непосредственно процессором.
А процессор обрабатывает звуковые данные, выполняет все действия чтобы донести эти данные до звуковой карты и плюс в большей или меньшей степени управляют самой звуковой картой. И да, упомянутый вами буфер действительно способен до некоторой степени сгладить звук. В общем-то во всех профессиональных программах для работы со звуком можно регулировать зависимость между размером буфера и величиной задержки. Но во первых, в случае коммутации нескольких устройств величина этой задержки становится критичной. А во вторых, буфер никак не способен “стабилизировать” работу ПО со звуковой картой, то есть обеспечить стабильную и максимальную реакцию системы на звуковые события и своевременную обработку оных.
yura_n, если имеет место “НЕсвоевременная обработка звуковых событий”, то есть когда программа не по скорости реакции (что ликвидируется за счёт буфера), а просто по средней производительности не успевает пополнять буфер – тут уже сложно чем-то помочь.

Но такое случается редко, так как производительность современных компьютеров на порядки выше чем у i386, и выражается не с “смазывании” и “непрозрачности”, а в грубых щелчках и “заиканиях” звука.

Откройте в звуковом редакторе какую-нибудь запись, лучше всего музыку, и попробуйте добавить в неё разрывов. Шириной эдак в один-два сэмпла. А потом послушайте, что получилось :)
Вы услышите ЩЕЛЧКИ. Конечно, если заполнить разрывы сэмплами с уровнем левого края, они уже не будут столь заметны, но что-то я не помню, чтобы звуковые карты отличались столь развитым интеллектом.
Natrio
yura_n, если имеет место “НЕсвоевременная обработка звуковых событий”, то есть когда программа не по скорости реакции (что ликвидируется за счёт буфера), а просто по средней производительности не успевает пополнять буфер – тут уже сложно чем-то помочь.
Как вы верно заметили звуковые карты вовсе не отличаются развитым интеллектом. Вы не обратили внимание на то, что процессор помимо всего прочего управляет звуковой картой. И делает он это не просто так, а какими-то программными средствами, посредством драйверов например. И если звуковая карта должна получить сообщение о том, что например нужно увеличить амплитуду, а это событие “застряло” на уровне ОС (процессор занят другими процессами, которые немного “подзадержались”), то каким образом ей поможет буфер? Речь идет о своевременном отклике, который как вы сами заметили, не всегда постоянен, вне зависимости от производительности.
yura_n, я уже описал выше, как примерно выглядит воспроизведение звука с помощью звуковой карты. Задержка в буфере – это именно задержка, и ничего более. За постоянство частоты сэмплов отвечает звуковая карта, а программы – за своевременное пополнение буфера. Своевременное – это значит не “точно в нужный момент”, а “НЕ ПОЗЖЕ нужного момента”, то есть буфер пополняется ЗАРАНЕЕ, в этом весь его смысл, со всеми плюсами и минусами.

Разумеется, минусы заключаются в том, что если перед вами стоит не банальная задача воспроизведения музыки плеером, а обработка звука в реальном времени, то конечно очень желательно, чтобы звук на выходе появлялся сразу, а не с задержкой, как при разговоре с Луной. Ну, как вот в этой статье, к примеру.

Что же касается обычных плееров, то в этом случае пресловутая задержка несущественна, если вы только не добиваетесь микросекундной реакции на кнопку Play :)
Что же касается обычных плееров, то в этом случае пресловутая задержка несущественна, если вы только не добиваетесь микросекундной реакции на кнопку Play :)
Глядишь так постов через 20 мы все-же поймем друг друга. :D Сама по себе задержка в случае обычного аудио-плеера несущественна. Существенна точная и своевременная обработка событий звуковой карты, а не только тех данных, которые находятся в буфере.
я хотел, про буфер аудиокарты написать, но подумал, что это слишком элементарно и пацаны наверное круто шарят, а я дурак ;)
такие дела.
lumberjack
менял я буфер – не помогает
И не поможет – у вас что-то другое.
Смотрите, не включён ли эквалайзер, эффекты, “replay gain”, не зашкалена ли громкость в плеере и микшере, и т.д.

yura_n, чтобы понять друг друга сразу – что именно вы имеете в виду под “событиями звуковой карты”?
Я воспринимаю это сочетание слов исключительно в прямом смысле, с точки зрения низкоуровневого программирования – прерывание, которым аудиокарта запрашивает пополнение буфера.
Natrio
yura_n, чтобы понять друг друга сразу – что именно вы имеете в виду под “событиями звуковой карты”?
Я воспринимаю это сочетание слов исключительно в прямом смысле, с точки зрения низкоуровневого программирования – прерывание, которым аудиокарта запрашивает пополнение буфера.
Под событиями звуковой карты я подразумеваю все случаи, которые требуют вмешательства CPU. А звуковая карта, как может быть вы думаете, это вовсе не отдельный (независимый) от системы модуль, значительная часть вычислений ложится именно на плечи процессора. Как программисту вам требуется только наполнить буфер. Но почему вы забываете про драйвер?
 
Зарегистрироваться или войдите чтобы оставить сообщение.