Jackd i PulseAudio.

Jackd + Chromium albo Firefox = problem. Tak się jakoś porobiło w Linuksie, że PulseAudio stało się standardem w obsłudze audio i chyba nie ma w tym nic złego. Mimo tego, że Firefox w Archlinuksie  skompilowany jest z obsługą jackd, to wyjście jackd w FF nie działa. Na szczęście nie jestem z obozu ultra-tradycjonalistów i udało mi się szybko i prosto pożenić jackd z Pulseaudio.

Potrzebny będzie pakiet pulseaudio-jack zawierający module-jack-sink.so i module-jack-source.so​.  Do /etc/pulse/default.pa trzeba dodać te moduły:

load-module module-jack-sink
load-module module-jack-source

Każdorazowo po odpaleniu jackd pulseaudio musi zostać przeładowane: pulseaudio -k, a potem: pactl set-default-sink jack_out. Dzięki temu pulseaudio przekieruje audio systemowe na jackd, co pozwala jak w moim przypadku bębnić w realtime do kawałków na Youtube. Pozytywne jest to, że po ubiciu jackd, PulseAudio przywraca odtwarzanie na defaultowej karcie dźwiękowej „w locie”.

Przykre, że jackd nie jest traktowane jak należy, a użytkowników w niszy audio na Linuksie chyba nie ma wielu i od przynajmniej dekady nic się w temacie nie robi, żeby im ułatwić życie.

Reklamy

Fsthost-svn + Hybrit + Lecab2 na Tahr Puppy (RT) :)

Fsthost-svn da się skompilować bez GTK i lash:

make GTK=0 LASH_PRESENT=0 PLAT=32

a mimo to, dodanie opcji -l -s plik.fps i potem kill -SIGUSR1 <pid> zapisuje stan wtyczki 🙂 (wielkie dzięki dla autora za wskazówki i cierpliwość).

chrt -f -p 89 `pidof jackd`
export WINE_RT=10; export WINE_SRV_RT=5
set_rlimits /usr/bin/fsthost -s ~/fsthost/brit.fps ~/poulin/HyBrit.dll&
set_rlimits /usr/bin/fsthost -s ~/fsthost/lecab.fps ~/poulin/Poulin_LeCab2_Rev1.dll&

i na wszelki wypadek:

pids=`pidof fsthost.so`
for pid in $pids; do chrt -f -p $pid; done

DSP load na poziomie <20% i brak xruns :). Co ciekawe, jak obciążę procesor np. klikoma pustymi pętlami while 1: pass, DSP run spada do 10-11%. Nadal uważam, że to zdecydowanie za dużo. Vsthost z dużym pluginem, typu GR5 generuje DSP load do 3% przy znacznie większej liczbie uruchomionych efektów… Ale raczej pozostanie to jako zagadka. Faktem jest, że te pluginy pod Linuksem działają lepiej jak pod Windows.

set_rlimits, bo w Puppim nie ma pam i /etc/security/limits.conf, a wine z łatką rt ma problem z priorytetami bez tego (trzeba przeedytować /etc/set_rlimits.conf).

Wysoki DSP load dla wtyczek VST Win32.

Staram się ograrnąć temat VST pod Linuksem i pomimo że nie jest najgorzej, zauważyłem dziwne zjawisko: wysoki DSP load i xruns w Ardour przez vst-bridge lub w Carli, przez jej własny bridge dla wtyczek VST. Dwa dni kombinacji i udało mi się zejść do nieco poniżej 50% (przez winetricks zainstalowałem gdiplus i vcrun205{08,10}, choć nie wiem czy to pomogło, dodałem też  i915.do_wbinvd=no do parametrów kernela, bo podobno sterowniki grafiki dają w kość, ale to dalej nie to! choć jeszcze wczoraj load skakał do 70-90%).

Najdziwniejsze jest to, że na starym vsthost z projektu dssi-vst DSP load jest na poziomie max 2-3% dla tych samych wtyczek. 

Ciekawe czy autor Carli, KXStudio i aktualny deweloper dssi-vst, Filipe Coelho aka falkTX, coś odpowie.

vst_host_low_dsp_loadardour_vst_bridgecarla_vst_bridgeCiekawe, że vst-bridge również cierpi na to samo „schorzenie”, choć działa nieco inaczej.

Update: zmieniłem IR loader na keFIR i da się żyć. DSP load na poziomie <40% xruns sporadycznie. Brzmienia darmowych symulacji wzmaków z dobrymi odpowiedziami impulsowymi cabinetów są lepsze od wszystkiego co słyszałem do tej pory w GR5.

Tahrpup 6 z kernelem RT.

Jestem zachwycony Puppim. Żadna inna dystrybucja nie wykorzystuje w ten sposób aufs (union type filesystem). Z pendrive działa to rewelacyjnie bo wszystko z systemu bazowego ładuje się do pamięci, a kolejne warstwy dogrywane są do obrazu aufs w pamięci z plików sfs. Dzięki temu pendrive się nie zużywa, a system jest bardzo szybki w odróżnieniu od typowej konfiguracji, w której zapisy i odczyty na pendrive powodują, że całość staje się niemal nieużywalna.Do pełni szczęścia potrzebowałem jedynie kernela RT ;). Pierwsze podejście – ze względu na dostępne wersje patchy RT – oryginalne źródła kernel_sources-3.14.11-tahr_PAE.sfs (już z łatkami z Puppiego) spaczowałem 3.14.12-rt8.patch. Et voila! A mój „Pro-audio” setup wygląda tak:

#!/bin/bash
cpufreq-set -g performance
echo 2048 > /sys/class/rtc/rtc0/max_user_freq
echo 2048 > /proc/sys/dev/hpet/max-user-freq
sysctl vm.swappiness=10
sysctl fs.inotify.max_user_watches=524288
#powyższe dwie linie raczej nie są potrzebne w puppim
setpci -v -d *:* latency_timer=b0
setpci -v -s 00:1b.0 latency_timer=ff #intel audio
jackd -R -P89 -dalsa -r44000 -p128 -n2 -D -Chw:0 -Phw:0 -Xseq&
qjackctl&
/etc/init.d/rtirq start
export WINE_RT=10; export WINE_SRV_RT=5
vsthost /some/where/VST.dll

Qjackctl używam ze względu na patchbay, który automatycznie łączy wcześniej zdefiniowane wejścia i wyjścia. Można więc e-drumsy podłączać i odłączać, albo np. zrobić suspend to ram i iść na siku 😉 gr

RT audio w głównej gałęzi Linuksa.

Byłem nieco zacofany w tym temacie. Okazało się, że od 2.6.39, czyli przynajmniej od roku, w stabilnym linuksie znalazła się opcja threadirqs, dzięki której do niskiej latencji audio nie trzeba już kompilować kernela z łatką RT. W praktyce, uruchomienie kernela z opcją threadirqs i dodanie do Archowego DAEMONS rtirq zapewnia 5ms opóźnienie  (pod wine/wineasio!), czyli dokładnie tyle co poprzednio po spaczowaniu łatką RT. Działa super. Jackd nie zgłasza xruns, nic się nie tnie, niezależnie od tego, co akurat dzieje się w tle.

Audio w linuksie RT.

Odkąd pojawił się Kubutek, a w zasadzie dość długo zanim się pojawił, niemal całkowicie zarzuciłem moje gitarowe brzdąkanie. Pewnie każdy rodzic czuje się wieczorem tak samo, człowiek jest tak zmęczony, że podpięcie gitary do komputera stanowi wyzwanie [1]. Od jakiegoś czasu mam drugiego laptoka (też Thinkpad R61 tylko w słabszej wersji z Celeronem), więc postanowiłem zrobić z niego czarne pudełko do którego na stałe podpięty jest interfejs audio (co ma też swoje plusy, bo można posłuchać jakiejś nowej płyty na słuchawkach) i gitara.

Problem z dźwiękiem jest w sumie ogólnosystemowy. Jak opóźnienia są zbyt duże, trzeszczy i piska, a czasem potrafi się przywiesić waląc szumem po uszach. Okazuje się znów, że konfiguracja:

  • procesor efektów w wine z wineasio
  • jackd -R
  • kernel RT z repozytorium debianowego Pengutronix

sprawdza się bardzo dobrze nawet na celeronie. Jackd działający z priorytetem RT i odpowiednio wysoki priorytet handlera IRQ załatwia sprawę. Jest to o tyle ciekawe, że taka konfiguracja w zupełności nie zaburza wygody używania systemu do innych celów i spokojnie można np. brzdąkać + podglądać/podsłuchiwać taba w tuxguitar i oglądać coś na YT.

Nie wiem na ile byłoby to wykonalne pod Windows, ale póki co, w kwestii audio pozostaję linuksiarzem, choć ostatnio jestem niebezpiecznie blisko porzucenia linuksa na domowym komputerze (po 12 latach przyjaźni z tym niedopracowanym systemem dla brodatych, niedomytych geeków… eh).

[1] Celowo piszę o podpięciu do komputera, bo głośne granie przy dziecku wieczorową porą odpada.

PS. Poeksperymentowałem wczoraj trochę z priorytetami, tak aby nie było żadnych opóźnień i nawet hardcorowa aktywność na komputerze nie generowała xruns. Najlepiej sprawdził się taki wariant:

  • handler przerwania usb na którym jest m-audio priorytet 99 (RT)
    (w /proc/interrupts można sobie po chwili działania dźwięku podglądnąć, na którym przerwaniu jest największy „ruch”)
  • jackd priorytet 99 (RT)
  • wine i program do symulacji efektów – wystarczy standardowy priorytet, bez zmian.

Torturowałem komputer nieskończonymi pętlami obciążającymi oba rdzenie w 100%, jednocześnie dało się spokojnie używać komputera  i przeglądarki – skutek – ani jednego xrun w jackd.

Powiem jedno: to jest na prawdę mocne. Czego by nie mówić o Alsie, linuksie jako całości, przy odrobinie chęci da się z linuksa zrobić profesjonalny system do zagadnień związanych z dźwiękiem.