LINUX.ORG.RU

Нестабильная задержка на USB-картах

 ,


0

2

Приветствую. Есть проблема синхронизации звука на USB-картах. Задержка менятся при каждой инициализации JACK-а, или смене размера буффера. Ситуация повторяется на различных дистрах (Fedora, (X/L)Ubuntu). Проверялось на E-MU 0202, на Behringer UCA-200. Задержка может поменяться при xrun-ах, или ещё от чего.

Для наглядности: открываю Ardour, кидаю семпл на дорожку, делаю loopback (соединяю физически вход и выход карты) и пишу семпл на другю дорожку, потом меняю размер буффера с 512 на 1024 и обратно на 512, снова пишу, и так несколько раз, вот что получаю: http://s2.ipicture.ru/uploads/20130906/MX6VDT4z.png Как видно, задержка каждый раз уникальна, дикий рассинхрон, она так же может меняться, как я говорил выше, от xrun-ов.

Как стабилизировать есть идеи? И вообще, это известное поведение? Потому что дело не пустяк, рассинхрон при записи — это проблема серьёзная.

Это проблема ALSA? Или JACK? Или ещё чего-то?

P.S. Так же плавающую задержку можно наблюдать в jack_iodelay.



Последнее исправление: unclechu (всего исправлений: 1)

Ответ на: комментарий от xSudo

RT не стоит, пробовал на lowlatency — тоже самое. Вот мне интересно, RT исправит ситуацию само по себе? Или может что-то надо будет поделать с ним? Я думаю я же не один, кто работает с USB-карточками, кто-то кроме меня должен был на эти грабли наступить, проблема известная?

Суть не в том, чтобы менять буфер во время записи, это для наглядности. Задержка меняется при xrun-ах, при каждом новом запуске JACK, что делает невозможным выставить при запуске -I и -O для автокомпенсации, потому что при перезапуске значение меняется. Случается какой-нибудь xrun при записи — нужно считать заново. И похоже на то, что задержка может измениться даже без фактического xrun-а, уследить за изменениями очень сложно.

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

unclechu
() автор топика
Последнее исправление: unclechu (всего исправлений: 1)
Ответ на: комментарий от xSudo

И хотел бы Вас поправить. Меняю буфер не во время записи, а после запуска джек. Во время записи буфер не меняется. Что в свою очередь является нормальной практикой, когда вдруг обнаруживается, что ЦП начитает надрываться и плеваться xrun-ами, и чтобы не перезапускать jack и всю прочую к нему коммутацию, — просто увеличить размер буффера, jack-ом это всё предусмотрено, в том числе предусмотрено и прямо в Ardour.

unclechu
() автор топика
Последнее исправление: unclechu (всего исправлений: 1)
Ответ на: комментарий от unclechu

Всё же рекомендую поставить RT. Завтра вечером (если не забуду) попробую поэкспериментировать, раньше к сожалению не смогу.

xSudo ★★★
()
Ответ на: комментарий от xSudo

Отловил так же нестабильную задержку и на PCI одной карте, какая-то из Sound Blaster от Creative.

Вопрос остаётся открытым, и кажется что это более чем серьёзный повод пересматривать архитектуру ALSA или ещё что-то там, по делу, неужели об этом ни слуху ни духу среди вертящихся «там»?

Вопрос пока решил, как и описывал ранее, loopback-ом, поработал паяльником, ножной футсвитч, при зажатии футсвитча на один (в конкретном случае правый) из входов вместе с сигналом с микрофона — идёт сигнал с одного из выходов (правый). В Ардуре 2-е дорожки, одна моно дорожка, на которую на вход принимается мастер-шина Ардура того канала, откуда был снят выход (правый), и вторая стерео-дорожка с 2-мя микрофонами. Запись идёт на обе эти дорожки, включаю 2-а или 4-е такта заранее, сразу заранее зажимая ногой футсвитч, перед там как подходит время играть, футсвитч отжимаю, играю. После записи тейка, делаю максимальный зум и сравниваю фазы в начале дорожки с записанным мастером ардура и один из каналов микрофонов, на глаз делаю сдвиг, чтобы фаза совпадала, всё. Других решений для тайм-перфектинга не вижу.

Вот так как-то: http://s1.ipicture.ru/uploads/20130921/yUx81Cu1.png

unclechu
() автор топика
Ответ на: комментарий от xSudo

Проверял так же и на RT-ведре, хоть и по субъёктивным меркам задержка стала несколько более стабильной, но всё-равно, каждый раз уникальная-новая.

unclechu
() автор топика
Ответ на: комментарий от unclechu

Хмммм. Даже нет предположений. У меня вроде бы всё без таких вот, «выкрутасов»... Может с материнкой чего не так, южный мост.

А на оффтопике всё нормально?

xSudo ★★★
()
Ответ на: комментарий от xSudo

На оффтопике не проверял, нет оффтопика. Чудо в том, что это повторяется не только на моей материнке, я проверял это как на своём ноутбуке, так и на другом компьютере. А вот имеется интересный факт, на встроенной карте, в ноутбуке, там какой бы буфер не стоял, — loopback-задержка всегда 32 фрейма, стабильная, и на всех размерах буффера одинаковая. Это меня несколько удивляет.

unclechu
() автор топика
Ответ на: комментарий от unclechu

Может кабель usb плохой? У меня разные карточки были и usb и куча pci сейчас вот firewire. Нигде рассинхрона не видел... Максимум - это большая задержка. jack какой версии стоит?

xSudo ★★★
()
Ответ на: комментарий от unclechu

Да всё в общем то всё стандартно. Сменой карточки)) Jack, rt, ну и конечно же понижением качества, и уменьшением буфера до приемлемых значений.

xSudo ★★★
()
Ответ на: комментарий от xSudo

То-есть просто минимизируя саму задержку? Это уже не компенсация, это уже стремление к реалтайм-мониторингу и доведение буффера до пределов погрешности) В этом случае уже не так важны эти смещения, на маленьком буффере они будут едва заметны.

Мне железо, к сожалению, такой радости не позволит.

unclechu
() автор топика
Последнее исправление: unclechu (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.