Полигон-2

Anderson1, фактически, CD-ROM отправляет плееру уже готовый 44 кГц PCM, так что последнему остаётся просто передать его на звуковую карту. Думаю, этот процесс вполне можно назвать воспроизведением, многие плееры такой режим поддерживают и т.п.
Тем более, что на CD-ROM'ах под это дело даже бывает дополнительный цифровой выход S/PDIF, который и правда, наверное, можно подключить напрямую к звуковухе.

До сих пор держу старенький 4-х скоростной креативовский ЦД-привод (лейбл "Quad Speed" на морде), у которого есть одновременно и аудио-выход под шнурок, и SPDIF выход (коакс) и IDE для связи с мамкой. Привод играет аудиоцд одновременно по всем трём интерфейсам! Более того, SPDIF выход у этого привода ещё не оболванен всякой копилефтией, и передаёт чистый, ничем не обработанный сигнал напрямую в TBS Pinnacle. У более современных приводов этот выход программно загрублён, ограничен по частотной полосе аудиосигнала, в угоду той самой копилефтии.

Попробуйте только назвать сие полным невоспролизведением цд!


uav1606 написал:

[q]

фактически, CD-ROM отправляет плееру уже готовый 44 кГц PCM

[/q]

Именно так. Цифровой цд-сектор очищается от шелухи цд-формата самим приводом, им-же примешивается некоторая "цифровая помеха" (на поздних приводах, с копилефтией inside), выравнивается по границе слова (обычно - за счёт кеша) и передаётся в мамку. Та переправляет данные в прогу пляйера/её кеш и затем на звуковую карту. Программный плйер не занимается конвертацией секторов цд в сектора "а-ля hdd", и не занимается очисткой потока от сервисной инфы. У него иная задача. Программный пляер обязан кешировать часть полученного потока на случай "перемотки", и поддерживать своевременный обмен с аудиокартой.

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


DrPass написал:

[q]

этим занимается драйвер CD-ROM, который использует аппаратную поддержку такого режима воспроизведения со стороны привода

[/q]

Драйвер сидюка не занимается конвертацией RaW audio потока в WAV PCM! Его задача - забрать цифру из кеша привода, закешировать её в RAM и выдать процу по первому его требованию. Именно процу, он перегонит инфу в пляер/кеш пляера, и затем в карточку.
Драйверу сидюка вообще по-шарабану, какой диск вставлен в привод! Он может лишь принять от привода сигнал "вставлен диск типа ХХХYYY" и передать эту инфу в ОС. Не более. Никакого собственного интеллекта.
C другой стороны, сам драйвер цд является веской причиной поместить привод мастером на отдельный канал IDE. Иначе - он мешает биосу/ОС общаться с винтом, влезая поперёк процесса обмена данных. Поначалу из-за этого портилась инфа на винче, позже - осталось лишь торможение обмена инфой на канале.

Anderson1 написал:

[q]

Это не воспроизведение у сидюка, а т.с. програмная эмуляция - плейер просто считывает данные, обрабатывает налету и т.о. проигрывает силами ЦПУ системы. Сидюк при этом ничего не проигрывает.

[/q]

Бред. Перечитай этот пост с начала, особенно внимательно - часть в ответ камраду DrPass.

uav1606 написал:

[q]

Что-то не понял эту сентенцию.

[/q]

Про генерацию прерываний не забудь. Драйвер сидюка их перехватывает (всегда), распознаёт а-ля "ах, это не моё" и возвращает винчу+ОС. Но времени(и ресурсов) на разруливание коллизии уходит немало, независимо от и в плюс ко торможению из-за шаринга линий данных.
А если в привод вставить заведомо глючный блин, то передача данных с винчом встанет на долгие минуты, покуда вклинившийся драйвер не опросит привод, не получит от него отбой, а тот не выдаст сигнала, покуда не завершит 100500 попыток чтения дефектного блина.
С другой стороны, разным каналам назначены разные прерывания, драйвер сидюка не перехватывает у винча ничего (как вариант, не видит винча вообще, ибо перехватывает совсем другое прерывание), коллизий не происходит. Заодно нет и шаринга линий данных.
Совсем современные ОС научились справляться с такими вещами и избегать коллизий, например, блокируя драйвер цд на время операций с винчом, благо драйвера - есмь часть самой ОС. Но это программный "костыль" и принципов не меняет. Стоит юзеру вставить/запустить аудио-цд одновременно с долгой архивацией длинного файла - хрип и заикания обеспечены, ибо костыль стал неэффективен.

Хорошо, что IDE ушёл в тору, бесконечно выбирать меж быстрой перезаписью меж винчами и отсутствием помех от цд-приводов - надоело. SATA уравнял в правах все типы приводов. Да, цыдюки всё-ещё тормозят дисковую подсистему собственной медлительностью, но уже не мешают одновременной скоростной перезаписи меж винчами. Здесь начинает играть роль тот факт, на котором контроллере подвешен винч-приёмник инфы. Чисто чтобы не был забит канал передачи данных внутри самого чипа контроллера.
Если три винча подвешены к одному сата-контроллеру, а ещё винч(или сидюк) - к другому сата-контроллеру, и скоростная перезапись ведётся меж первыми двумя винчами первого контроллера, то скорость этой передачи упадёт, если на третий винч начать переливать инфу со второго контроллера, неважно, с какого источника.

uav1606 написал:

[q]

С аудио-CD могут быть тормоза только если воспроизведение идёт через IDE

[/q]

Так, речь как раз об IDE.
Со шнурками всё скучно до обыденности: воткнул - есть звук, вынул - нет звука, вывернул разъём - спалил привод.
uav1606 написал:

[q]

Прерывания, вообще говоря, разруливает драйвер контроллера, а не конкретно драйвер CD или винта. А он уже решает, чьё это прерывание и что с ним делать.

[/q]

Как драйвер сидюка вклинивается в управление контроллером? Как надстройка над драйвером контроллера! Так-что прерывания он перехватывает, всегда. И UDMA-запросы он тоже всегда перехватывает. Другое дело, ОС может временно запретить ему своеволие, в некоторых пределах.

uav1606 написал:

[q]

И надстройка эта получает управление только при необходимости, когда идёт обмен данными с CD.

[/q]

Увы, вертикальную (луковую) модель прохождения данных сквозь надстройки над контроллерами - никто не отменял (кроме SATA).

Драйвер сидюка обволакивает собой драйвер IDE и добраться к последнему, не затронув драйвер сидюка - невозможно. Иными словами, драйвер IDE внедряется в драйвер сидюка и становится его неотъемлемой частью.
uav1606 написал:

[q]

достаточно глянуть на ресурсы в Диспетчере устройств - у контроллера они перечислены (порты, IRQ и т.п.), а в ветке с приводами у CD\DVD никаких ресурсов нет.

[/q]

Если присмотришься внимательнее - драйвер есть у каждого из каналов IDE. Если привод с винчом висят на одном шлейфе, драйвер сидюка обернёт драйвер этого канала и постоянно будет мешать. Если привод висит отдельно на втором канале, драйвер сидюка "пожрёт" драйвер только второго канала, и мешать будет только ему. Винчи на первом канале будут свободны от влияния драйвера цд.
CD/DVD ресурсы не нужны, оные полностью пожирают ресурсы канала IDE.