Стоп. Добавлялся сэмпл это из другого балета - нельза вот так взять и добавить сэмпл без разрыва фазы. Мы получается о разном говорили...
На исходники - нет. Но могу объяснить, там ничего сложного нет. Поднимаем частоту дискретизации во много раз (у меня в 512 раз), после этого вычисляем где должен быть нужный нам сэмпл, после этого делаем интерполяцию (в простейшем случае линейную) по соседним сэмплам интерполированного сигнала и получаем сэмпл, который находится в нужной точке оси времени. А сами точки, где должны у нас быть сэмплы выходного потока вычисляем на основании соотношения частот дискретизации на входе-выходе ASRC.
В той теме меня уже в этом убедили... когда сделаю ASRC просто будет подключаться в те же моменты что и сейчас - и будет делать 6 * 57 сэмплов из (6 * 57) + 1 или из (6 * 57) - 1 входных, полсле чего ждать следующего повода...
Про практику - в одноминутных сеансах передачи WSJT необходимость ресэмплинга не возникает, все решается в пределах допустиимых колебаний размера очереди.
а вот так можно сделать, я так понимаю это речь идет о данных от хоста в МК?
Последний раз редактировалось R3DI; 07.08.2017 в 00:11.
Если интересно - в исходниках mcHF не стали с ASRC заморачиваться пока, функция AUDIO_AudioCmd_FS использует тот же способ выкидывания/вставки (даже без среднего по сосседним) сэмпла.
Я так понимаю, romanetz которгого я упоминал и который писал в моей теме раньше (и оказал мне громадную помощь в разбирательстве с USB общаясь вне форума) описывает вариант на таймерах - который Олег использует? Наверное, можно и так сделать.можно сделать, я так понимаю это речь идет о данных от хоста в МК?
Последний раз редактировалось Genadi Zawidowski; 07.08.2017 в 00:37.
Это не будет ASRC - ASRC работает не так. Его другое название fractional resampler - возможно оно на какие-то мысли наведет. То, что Вы описываете будет эквивалентно оцифровке с периодически прыгающим клоком. ASRC должен работать всегда пересчитывая каждый сэмп под нужное время.
Это не мой путь К тому же когда пишешь аудио то есть реальная необходимость, чтобы все работало по много часов.в одноминутных сеансах передачи WSJT необходимость ресэмплинга не возникает.
Да он тоже вторым таймером измеряет соотношение частот, но ресэмплинг, как я понял, делается хостом через асинхронный аудио интерфейс. У меня же ресэмплинг делается девайсом (stm32) поэтому все пакеты одинаковой длины, ну и я полностью контролирую этот процесс, ибо к внутренностям винды нет доверия у меня, да и помнится официально асинхронное аудио винда не поддерживает (по крайней мере далеко не все версии которые достаточно широко используются).
Думаю там со многим "не стали заморачиваться" Я же приводил разные примеры того, что выходит - меня это не устраивает. Более того драйвера в E-MU0202 тоже небезгрешные и ресемплинг там делается кривовато - на слух этого не слышно, но очень мешает когда меряешь SpectraLABом или чем-то подобным.
При чем тут "пишешь по много часов"? В эту сторону то оно точно без пинков работает. О каких таких версиях виндов речь? Хп, 7, 10 проверены- приём бпск везде работал. Что-то из восьмых видов?
ХР официально поддержки асинхронного аудио не имела.
Ну значит хорошо А насколько качественный ASRC в винде?
Добавлено через 6 минут(ы):
Собственно вот:
https://answers.microsoft.com/en-us/...1-a3eddd89d7f9
Поддержка асинхронного аудио появилась начиная с Висты.
Последний раз редактировалось UR3IQO; 07.08.2017 в 10:14.
Весь смысл проекта асинхронного юсб, чтобы никакого ресемплинга вообще не было. Девайс является источником качественного клока (и соответственно семплов), а выравнивание с хостом достигается за счёт явной обратной связи. Это доступный способ получить bit-perfect, из-за чего на этом помешан весь мир Hi-Fi/Hi-End. Всё это работало в серийных девайсах во времена ХР, а теперь и подавно.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)