I²S (рус. ай-сквэ́ард-эс / и-два-эс ) — стандарт интерфейса электрической последовательной шины, использующийся для соединения цифровых аудиоустройств. Применяется для передачи ИКМ-аудиоданных между интегральными схемами в электронном устройстве. Шина I²S передает по разным линиям сигналы синхронизации и сигналы данных, что приводит к снижению фазового дрожания, типичного для систем связи, восстанавливающих сигналы синхронизации из целого потока. Название представляет собой аббревиатуру слов Integrated Inter-chip Sound.
Этот стандарт был введен в 1986 году и последний раз был пересмотрен в 1996 году.
Интерфейс I²S электрически представляет собой 3 проводника, которые идут от активного устройства к пассивному, а также 4 сигнала, им соответствующие следующим образом:
- Тактовый сигнал битовой синхронизации (CLK)
- Тактовый сигнал фреймовой (по словам) синхронизации (WS)
- Сигнал данных, который может передавать или принимать 2 разделённых по времени канала. (SD) [1]
Каналы для приёма и передачи данных разделены, то есть существуют отдельно канал для приёма данных и канал для передачи данных. Контроллер принимает данные, передаваемые звуковым кодеком, но возможна и обратная ситуация.
Содержание
Форматы [ править | править код ]
Существуют два формата передачи данных по звуковому интерфейсу — I²S и DSP (Digital Signal Processing, цифровая обработка сигналов), в которых идет двухсторонний обмен данными, регулируемый активным устройством (контроллером). В формате I²S фреймовая синхронизация задает смену канала. Низкий уровень кадровой синхронизации задает левый канал, высокий — правый. Тактовые сигналы не изменяются (не прерываются) в отличие от приборного интерфейса. Тактовый сигнал подается непрерывно, что упрощает алгоритм.
С приходом сигнала кадровой синхронизации с задержкой на один или два такта начинают передаваться или приниматься данные, причем идет передача начиная со старшего, более значащего разряда. Изменяя длительность кадровой синхронизации, можно изменять число передаваемых разрядов, отсчетов сигналов. Поэтому в общем случае будет число N передаваемых бит — число тактовых интервалов, которые будут использоваться для передачи данных. Но после того как данные требуемой длины переданы, наступает пауза до прихода следующего перехода сигнала кадровой синхронизации. По этому переходу передают или принимают данные по другому каналу. Смещение относительно перехода сигнала кадровой синхронизации до начала приема данных настраивается конфигурированием контроллера, который управляет передачей данных. Далее передаются разряды, которые равны по числу разрядов левого канала и правого канала, это повторяется, то есть попеременно передаются отсчеты левого и правого сигнала.
Согласно заявленной спецификации, стандарт I²S обладает следующими параметрами
- Программно конфигурируемое разрешение 16/32 бит;
- Стабильность тактирования: не менее 0,5 %
- Возможность работать в режимах ведущего и ведомого;
- Поддержка частот семплирования от 8 до 192 кГц;
- Два независимых приемопередатчика. [1]
Формат DSP ведет себя иначе — он требует синхронизацию в виде импульса с большой скважностью, каналы передает как удвоенное число разрядов, чтобы упростить прием и передачу. И в этом случае имеется последовательная передача разряда от левого канала, а потом без пропусков разрядов правого канала. Далее следующий импульс приходит и цикл повторяется.
Организация контроллера [ править | править код ]
Контроллер имеет две части, а также блок внешних выводов. Они отвечают за данные, передаваемые и принимаемые по одному проводнику, а также за сигналы тактовой и кадровой синхронизации. Контроллер передает их, управляя процессом обмена. Чтобы устройство работало корректно, нельзя менять вход с выходом, ибо обратное может привести к цифровой петле.
Первая часть — сам контроллер со входами. Для работы ему нужен генератор тактовой частоты, который выдает события канала прямого доступа. Прием-передача звука может осуществляться не микропроцессором, а каналом прямого доступа, специальным процессором для ввода-вывода данных. Этот канал прямого доступа нуждается в событиях начала считывания данных регистров приема или передачи данных в регистры передаточные.
Вторая часть — регистры интерфейса, предусмотрены следующие их типы:
- Регистры флагов прерывания;
- Регистр разрешения прерываний от того или иного источника (по числу флагов прерывания или по числу разрядов регистра разрешения прерываний)
- Регистр управления, в котором задаются режимы работы контроллера;
- Регистр генератора частоты выборки, в котором можно задавать тактовый сигнал и его частоту для битовой синхронизации — если данные принимаются, то регистр записывает эти данные и те могут быть подсчитаны программно;
- Два регистра приема данных;
- Регистры передачи данных по каналам, в которых могут быть два 32-х битовых регистра, передаваемых последовательно.
Сигналы прерывания говорят о том, какие события возникли внутри контроллера и нуждаются в обработке. Существуют две группы прерываний: первая есть прерывания, связанные с приемом и передачей данных и событий, вторая — связанные с обработкой и генерацией тактовых сигналов. Она вырабатывает сигналы для канала прямого доступа и контроллера прерываний.
Если устройство пассивное (играет роль ведомого), то сигналы поступают извне в синхронизатор. В одном случае он принимает и усиливает, переформировывает тактовые сигналы, делая из плавных по контуру в четкие и резкие. В другом случае он выдает сигнал синхронизации во внешнее устройство. Сигналы блока, отвечающего за разрешение или запрещение работы, формируются по состоянию бита в регистре управления.
Обработчик прерываний сперва производит чтение регистра флагов прерываний для их последующего сброса. Далее читает или записывает данных в регистры данных I²S, если не используется канал прямого доступа. После этого происходит возврат из прерывания.
Конфигурационные опции задают для синхронизатора полярность битовой и кадровой синхронизации. Эти данные помогают синхронизатору выбрать режим работы звукового интерфейса.
Приём данных [ править | править код ]
Последовательный приёмник четко фиксирует уровни сигналов, которые тактируются синхронизатором. Далее эти данные побитно поступают по линии принимаемых данных в регистр сдвига, который синхронизирует данные от синхронизатора. После того, как регистр сдвига запомнится, он переписывается в буфер регистра приёма. Размер разрядности регистра сдвига задается длиной слова. После того, как буфер регистра регистрирует принятые данные, может произойти расширение знака. Так как заведомо используется формат с фиксированной запятой, надо расширить знак до 32-х разрядов, получив 12 разрядов данных. Старший разряд полученных данных распространяется во все старшие разряды регистра, чтобы было правильное число, представленное в дробном формате.
Передача данных [ править | править код ]
Данные из регистра считываются в схему сужения знака, которая отбрасывает лишние разряды, сужает знак, выделяет передаваемые данные и записывает их в буфер передачи. Она сужает знак с разных частей и число записывается в соответствующие разряды передатчика. Как только регистр сдвига освободится, одновременно записываются биты сдвига и начинают выдвигать по одному разряду, начиная со старшего, передавая данные в передатчик, которые передает данные в выходную цепь.
Тактовое питание [ править | править код ]
Существует схема, которая отвечает за подачу тактового питания на устройство. Для этого в ней предусмотрен читальный регистр, то есть регистр конфигурации затворов тактового питания. Если подать ноль, то его значение станет единицей и сигнал пойдет. Если будет единица, то произойдет затвор, другими словами тактовое питание при единице на устройство подаваться не будет. Имеются две формулы — тактовая и кадровая синхронизация. В каждой из них берется частота, которая поступает в первый тактовый сигнал и делится на то число раз, которое задано в регистре делителя тактовой частоты или в регистре делителя кадровой частоты.
Завершение ввода-вывода [ править | править код ]
Для завершения процесса ввода-вывода необходимо последовательно запретить прерывание, очистить флаги, остановить канал прямого доступа и снять тактовое питание.
Учимся передавать звук с использованием протокола I2S
13 августа 2018
I2S (Inter-IC Sound) — это цифровой протокол передачи звука, который довольно часто используется в современной электронике. I2S не имеет ничего общего с I2C кроме похожего названия, поэтому важно эти протоколы не путать. В рамках сего поста мы постараемся разобраться, на что вообще похож I2S, и как с ним работать.
На базе устройств, использующих I2S, существует немало готовых плат, в частности:
- У Adafruit есть два микрофона — первый и второй;
- DAC на базе чипа UDA1334A можно купить у той же компании;
- Еще есть DAC с усилителем MAX98357 для вывода звука на динамик;
- На Tindie можно купить I2S-микрофон на базе ICS43434;
- На том же сайте был найден DAC на базе чипа CS4344;
При написании этого поста я использовал PmodI2S производства компании Digilent. Данный модуль построен на базе чипа CS4344 (типичная маркировка «344C 1609», даташит [PDF]). Устройство было приобретено в Чип-и-Дипе, но на момент написания этих строк оно успело куда-то пропасть с сайта магазина. Впрочем, для повторения описанных далее шагов вы можете использовать любой аналогичный модуль. Внешний вид использованного мной модуля:
Типичный I2S-сигнал выглядит в PulseView как-то так:
Здесь SCK представляет собой тактовый сигнал. WS (он же LRCLK) отвечает за выбор канала. Через SDA (он же SDIN) передаются сами данные. Сигнала MCLK, строго говоря, нет в спецификации I2S [PDF]. Но на практике многие устройства используют его для синхронизации своих внутренних операций. Обычно сюда идет тактовый сигнал с частотой в 256 раз больше частоты дискретизации звука.
Fun fact! Если хочется извлечь звук из записанного I2S-сигнала, это можно сделать такой командой:
Для экспериментов с модулем я воспользовался отладочной платой Nucleo-F411RE. Микроконтроллер, используемый в этой плате, имеет аппаратную поддержку I2S, которой и было решено воспользоваться. Какие настройки доступны в STM32CubeMX и к каким пинам микроконтроллера следует подключать модуль, вы без труда разберетесь самостоятельно по полной версии проекта. Поговорим лучше непосредственно о коде.
Например, генерация синусоидального сигнала с частотой 100 Гц осуществляется так:
#define PI 3.14159265358979323846
#define TAU (2.0 * PI)
void loop ( ) <
HAL_StatusTypeDef res ;
int16_t signal [ 46876 ] ;
int nsamples = sizeof ( signal ) / sizeof ( signal [ 0 ] ) ;
int i = 0 ;
while ( i nsamples ) <
double t = ( ( double ) i / 2.0 ) / ( ( double ) nsamples ) ;
signal [ i ] = 32767 * sin ( 100.0 * TAU * t ) ; // left
signal [ i + 1 ] = signal [ i ] ; // right
i += 2 ;
>
while ( 1 ) <
res = HAL_I2S_Transmit ( & hi2s2 , ( uint16_t * ) signal , nsamples ,
HAL_MAX_DELAY ) ;
if ( res != HAL_OK ) <
UART_Printf ( "I2S — ERROR, res = %d!
" , res ) ;
break ;
>
>
>
Интересно, что по каким-то причинам микроконтроллеры STM32 не могут использовать традиционные значения частоты дискретизации, такие, как 44100 Гц или 48000 Гц. В частности, при выборе частоты 48000 Гц реальная частота составит 46876 Гц (на 2.34% меньше). Впрочем, на слух такая разница совершенно незаметна. Все эти различия между желаемой и реальной частотой отображаются прямо в STM32CubeMX.
Кажется, похоже на правду.
Но это еще не все. Если вы попытаетесь, например, просто взять и проиграть WAV-файл с SD-карты «в лоб», то у вас ничего не получится. Звук будет периодически обрываться и слушать такое будет совершенно невозможно. Решение заключается в том, чтобы использовать прерывания и двойную буфферизацию. Другими словами, параллельно с проигрыванием одного отрывка файла должен читаться следующий отрывок. Таким образом, когда проигрывание текущего отрывка завершится, следующий отрывок будет уже готов, и не придется тратить время на его чтение с SD-карты (что и является источником обрывов в звуке).
volatile bool end_of_file_reached = false ;
volatile bool read_next_chunk = false ;
volatile uint16_t * signal_play_buff = NULL ;
volatile uint16_t * signal_read_buff = NULL ;
volatile uint16_t signal_buff1 [ 4096 ] ;
volatile uint16_t signal_buff2 [ 4096 ] ;
void HAL_I2S_TxCpltCallback ( I2S_HandleTypeDef * hi2s ) <
if ( end_of_file_reached )
return ;
volatile uint16_t * temp = signal_play_buff ;
signal_play_buff = signal_read_buff ;
signal_read_buff = temp ;
int nsamples = sizeof ( signal_buff1 ) / sizeof ( signal_buff1 [ 0 ] ) ;
HAL_I2S_Transmit_IT ( & hi2s2 , ( uint16_t * ) signal_play_buff , nsamples ) ;
read_next_chunk = true ;
>
int playWavFile ( const char * fname ) <
UART_Printf ( "Openning %s.
" , fname ) ;
FIL file ;
FRESULT res = f_open ( & file , fname , FA_READ ) ;
if ( res != FR_OK ) <
UART_Printf ( "f_open() failed, res = %d
" , res ) ;
return — 1 ;
>
UART_Printf ( "File opened, reading.
" ) ;
unsigned int bytesRead ;
uint8_t header [ 44 ] ;
res = f_read ( & file , header , sizeof ( header ) , & bytesRead ) ;
if ( res != FR_OK ) <
UART_Printf ( "f_read() failed, res = %d
" , res ) ;
f_close ( & file ) ;
return — 2 ;
>
if ( memcmp ( ( const char * ) header , "RIFF" , 4 ) != 0 ) <
UART_Printf ( "Wrong WAV signature at offset 0: "
"0x%02X 0x%02X 0x%02X 0x%02X
" ,
header [ 0 ] , header [ 1 ] , header [ 2 ] , header [ 3 ] ) ;
f_close ( & file ) ;
return — 3 ;
>
if ( memcmp ( ( const char * ) header + 8 , "WAVEfmt " , 8 ) != 0 ) <
UART_Printf ( "Wrong WAV signature at offset 8!
" ) ;
f_close ( & file ) ;
return — 4 ;
>
if ( memcmp ( ( const char * ) header + 36 , "data" , 4 ) != 0 ) <
UART_Printf ( "Wrong WAV signature at offset 36!
" ) ;
f_close ( & file ) ;
return — 5 ;
>
uint32_t fileSize = 8 + ( header [ 4 ] | ( header [ 5 ] 8 ) |
( header [ 6 ] 16 ) | ( header [ 7 ] 24 ) ) ;
uint32_t headerSizeLeft = header [ 16 ] | ( header [ 17 ] 8 ) |
( header [ 18 ] 16 ) | ( header [ 19 ] 24 ) ;
uint16_t compression = header [ 20 ] | ( header [ 21 ] 8 ) ;
uint16_t channelsNum = header [ 22 ] | ( header [ 23 ] 8 ) ;
uint32_t sampleRate = header [ 24 ] | ( header [ 25 ] 8 ) |
( header [ 26 ] 16 ) | ( header [ 27 ] 24 ) ;
uint32_t bytesPerSecond = header [ 28 ] | ( header [ 29 ] 8 ) |
( header [ 30 ] 16 ) | ( header [ 31 ] 24 ) ;
uint16_t bytesPerSample = header [ 32 ] | ( header [ 33 ] 8 ) ;
uint16_t bitsPerSamplePerChannel = header [ 34 ] | ( header [ 35 ] 8 ) ;
uint32_t dataSize = header [ 40 ] | ( header [ 41 ] 8 ) |
( header [ 42 ] 16 ) | ( header [ 43 ] 24 ) ;
UART_Printf (
"— WAV header —
"
"File size: %lu
"
"Header size left: %lu
"
"Compression (1 = no compression): %d
"
"Channels num: %d
"
"Sample rate: %ld
"
"Bytes per second: %ld
"
"Bytes per sample: %d
"
"Bits per sample per channel: %d
"
"Data size: %ld
"
"——————
" ,
fileSize , headerSizeLeft , compression , channelsNum ,
sampleRate , bytesPerSecond , bytesPerSample ,
bitsPerSamplePerChannel , dataSize ) ;
if ( headerSizeLeft != 16 ) <
UART_Printf ( "Wrong `headerSizeLeft` value, 16 expected
" ) ;
f_close ( & file ) ;
return — 6 ;
>
if ( compression != 1 ) <
UART_Printf ( "Wrong `compression` value, 1 expected
" ) ;
f_close ( & file ) ;
return — 7 ;
>
if ( channelsNum != 2 ) <
UART_Printf ( "Wrong `channelsNum` value, 2 expected
" ) ;
f_close ( & file ) ;
return — 8 ;
>
if ( ( sampleRate != 44100 ) || ( bytesPerSample != 4 ) ||
( bitsPerSamplePerChannel != 16 ) || ( bytesPerSecond != 44100 * 2 * 2 )
|| ( dataSize sizeof ( signal_buff1 ) + sizeof ( signal_buff2 ) ) ) <
UART_Printf ( "Wrong file format, 16 bit file with sample "
"rate 44100 expected
" ) ;
f_close ( & file ) ;
return — 9 ;
>
read_next_chunk = false ;
end_of_file_reached = false ;
signal_play_buff = signal_buff1 ;
signal_read_buff = signal_buff2 ;
HAL_StatusTypeDef hal_res ;
int nsamples = sizeof ( signal_buff1 ) / sizeof ( signal_buff1 [ 0 ] ) ;
hal_res = HAL_I2S_Transmit_IT ( & hi2s2 , ( uint16_t * ) signal_buff1 ,
nsamples ) ;
if ( hal_res != HAL_OK ) <
UART_Printf ( "I2S — HAL_I2S_Transmit failed, "
"hal_res = %d!
" , hal_res ) ;
f_close ( & file ) ;
return — 12 ;
>
while ( dataSize >= sizeof ( signal_buff1 ) ) <
if ( ! read_next_chunk ) <
continue ;
>
dataSize -= sizeof ( signal_buff1 ) ;
>
res = f_close ( & file ) ;
if ( res != FR_OK ) <
UART_Printf ( "f_close() failed, res = %d
" , res ) ;
return — 14 ;
>
Передача данных по I2S осуществляется асинхронно при помощи процедуры HAL_I2S_Transmit_IT . По завершении передачи данных вызывается коллбэк HAL_I2S_TxCpltCallback . Если это известно, то остальная часть кода становится тривиальной.
Напомню, что с форматом WAV-файлов и библиотекой FatFs мы ранее познакомились в рамках статей Парсинг заголовка и проигрывание WAV-файла на Scala и Работа с FAT32 и exFAT с помощью библиотеки FatFs соответственно.
Вот и все, о чем я хотел сегодня рассказать. Исходники к этому посту вы найдете на GitHub. Если у вас есть вопросы или дополнения, используйте комментарии, не стесняйтесь!
Как я гонял I2S по обычному патчкорду Fast Ethernet CAT5
Накрывшее меня разочарование было неожиданным. Как так?
При массе восторгов от способа передачи информации по этой чудесной шине, о приросте качества звучания, и прочих положительных моментах не оказалось ни одного законченного схемного решения уровня «корпус источника» — «корпус ЦАП».
А так как транспорт у меня это ПК с выводом по USB, то именно решение «корпус» — «корпус» самый оптимальный вариант.
Да и на рынке все чаще стали появляться вполне высококачественные решения USB-транспортов с выходом I2S TTL.
В общем нужно продумать линк, позволяющий гнать I2S от транспорта до ЦАП в TTL формате, да еще и с гальваноразвязкой.
Вообще для подобных целей технически грамотно было бы использовать шину LVDS, но кроме явных плюсов в виде большого расстояния передачи, симметричных линий, имеем и свои минусы — дороговизна и труднодоставаемость микросхем приемопередатчиков, необходимость использования специальных разъемов, отсутствие гальваноразвязки.
Мне же нужно расстояние на более полуметра, но вот как это организовать?
Сразу же в голове нарисовалась картина: куча экранированных проводов, позолоченный разъем.
Ах да! Разъем! Поиск как обычно дал «массу вариантов». Кто-то использовал DB-9 — разъем от СОМ порта ПК. Но моя «личная неприязнь» к нему как к разъему не позволила остановиться на этом решении.
А что применяют иностранцы в своих вариантах USB-транспортов? Недолгий поиск и есть ответ — RG45. Восьмиконтактный пластиковый обжимной разъем, применяющийся в сетевой инфраструктуре стандарта Fast Ethernet (100BASE-T)!
Четыре изолированных витых пары!
— Шикарно!- сказал я.
— Ага!- сказал поисковик — А распиновка?
— Давай, попробуй.
"I2S pinout", "RG45 I2S" и еще тридцать два варианта.
— Нету?
— Да ты искать не умеешь!
И правда не умею. Так как из всего найденного «фабричного» интересными было два варианта — Northstar DAC Model 192 MKII и Terralink X, решено было остановиться на них.
У всего остального найденного было что-то не совсем вменяемое, включая фантомное питание +5В. Ну и информации о соединительном кабеле, применяемом с этими устройствами тоже не смог найти. Ну в общем то раскладка Terralink меня устраивала, так как окзалось, что она попарно совпадала с распиновкой стандартного патчкорда.
Ну хоть где-то что-то будет по стандарту! Хотя здесь я сделаю отступление.
Следование стандарту на этот момент уже не было моей целью, не на продажу же, а вот применение максимального количества стандартных компонентов было желательно.
Итак, что мы имеем?
Патчкорд. И дикое желание что-то сваять. Осталось продумать устройство вывода и устройство ввода.
В качестве устройства вывода был изготовлен на коленке формирователь USB-I2S с использованием РСМ2707.
Как буфер-конвертер TTL утровней – 74АС573.
Для тестирования в самый раз. В дальнейшем планировалось использование аудиоконтроллера USB-I2S TAS1020, ну и что-нибудь возможно посерьезнее.
Теперь необходимо продумать приемную сторону.
Тут немного сложнее. Во-первых нужно внести в схему ЦАП систему коммутации входов между ресивером SPDIF и цифровым фильтром.
Здесь можно воспользоваться мультиплексором четырехканальным, типа 74хх157/257.
А во вторых. А как быть во-вторых? Ведь самое проблемное место — гальваноразвязка. Это дома заземление, отдельная нейтраль.
А в любом другом месте ушатать ЦАП или источник не хотелось бы. Раз не применяем LVDS, то RS485 можно попробовать.
Как приемная часть SPDIF потока. По частоте MCLK вроде проходит, лишь бы трансы позволили.
Ну четырех штук ADM1485 в наличии не было, зато в хламе нашлась АМ26С32. То же самое, только четыре канала на корпус — не я один видимо такой ерундой занимаюсь. Но на проверку, такая схема оказалась неработоспособна.
Или мои кривые руки что-то не так сделали.
Мало того, что мастерклок не корректно пролазил через трансформаторную развязку, чего я и боялся, так еще и на шине данных в паузах был посторонний шум, приводящий к сбоям в работе ЦАП, а то и полном зависании ЦФ.
В чем проблема? Может витая пара не позволяет гонять такие данные без коррекции ошибок? Несимметричная линия? Попробовать экранированный провод?
Но не каждый кабель возможно запихать в RG45.
А ведь уже сделана плата, установлен мультиплексор, ЦАП работает без проблем в режиме SPDIF от DIR9001.
Бросать на половине пути ?
В какой то момент мой взгляд упал на кабель SATA, что лежал на столе. Кусачки в руки и в руках у меня плоский четырехжильный экранированный провод! Ну конечно там система 2+2, но уже что-то!
Заделать его в разъем RG45 большого труда не составило, разве что домотать изоленту на концы, чтоб надежно прижать замками коннекторов.
Вполне сносно получилось. Но все равно не работает!
Ладно, выкидываю приемную часть, выпаиваю очередной разъем со старой сетевухи, включаю напрямую, без гальваноразвязки.
Ага! ПоетЬ! Но есть проблема.
Так как уровни на выходе с размахом в 5В, а питание мультиплексора 3,3В, то сигналы «пролазят» через закрытый вход при работе от DIR9001.
Шум и потрескивание не сильно приятно.
Ладно, надо попробовать конвертер. Из хлама извлекаю 74АС245, которая по даташиту справляется с уровнями в 5В при питании 3,3В и горожу на коленке такую схему:
Завелось все с полпинка! Работает и с SATA проводом, и на стандартном патчкорде! Ни помех, ни выпадений сигнала!
Но отсутствует вторая часть задания — гальваническая развязка. Печально, но придется заказывать digital isolator.
Вообще, этих цифровых развязок есть много типов. Различаются они, в основном, числом каналов, принципом работы, направлением передачи – приема, пропускной способностью и производителем. Интересные девайсы.
Раздельное питание, работа с 3,3В и 5В. Мне нужно четыре канала на прием.
Из найденного в сети подходят: ADuM1400, IL715, ISO7240.
Заказал IL715, по даташиту она как раз под AD/DA заточена, да и доступна относительно. А заодно и DC/DC конвертер на 5В. Ведь питать входную часть надо от источника, что не предусмотрено конструктивом, либо от самого приемника, но при этом развязать гальванически его от входа.
Пока все это ехало, накидал схему развязки.
И внес изменения в плату самого ЦАП.
Добавил мультиплексор и сделал отключение питания приемника DIR9001 при работе от I2S.
А также доработал индикацию режимов.
Теперь, при работе от SPDIF индикатор показывает текущую частоту дискретизации, а при работе от I2S — три горизонтальных черты.
Включение и запуск никаких проблем не принесли, все было ожидаемо и проверено заранее.
Работа четкая, без сбоев.
В идеале, развязку надо было бы установить на основную плату, например вместо приемника DIR9001 или рядом, но для этого пришлось бы полностью переделать трассировку всей платы, и размер бы сильно изменился.
Поэтому метод «бутерброд» показался самым оптимальным. Да и провода соединительные покороче будут.
Сверху коробочка — USB/I2S аудиоконтроллер на базе TAS1020.
Ну и традиционное «как оно?». Стравить SPDIF и I2S «в лоб» не получилось, по крайней мере на слух.
Проблема в том, что ни один из моих источников параллельно не может отдавать и то и другое.
Пока переключаешь источники, ухо «остывает» и разницы уловить невозможно.
Но самое главное — это опыт и возможность дополнительной модернизации. Тем более запланирован нормальный источник, с возможностью внешнего тактирования. А тогда можно и пересинхронизацию и ЦАП в режиме «мастер». Так что может кому-то это будет интресно.
Файлы здесь:
▼ I2S.zip 🕗 06/06/13 ⚖️ 137,64 Kb ⇣ 177
Здравствуй, читатель! Меня зовут Игорь, мне 45, я сибиряк и заядлый электронщик-любитель. Я придумал, создал и содержу этот замечательный сайт с 2006 года.
Уже более 10 лет наш журнал существует только на мои средства.
—
Спасибо за внимание!
Игорь Котов, главный редактор журнала «Датагор»
А я думаю, продолжение последует.
Алексей
