OpenBSD, mint "hangszer"

 ( trey | 2015. február 12., csütörtök - 16:11 )

Alexandre Ratchov (ratchov@), az OpenBSD audio alrendszerének fejlesztője szokatlan módon koncertre invitál. A koncertet a francia Grenoble városban, a "the Hexagone"-ban tartják 2015. február 27-én. Hogy ez hogyan kapcsolódik az OpenBSD-hez? Úgy, hogy a koncerten használt szintetizátorok és effektprocesszorok 64 bites OpenBSD-n futnak.

A hardver egy korszerű desktop gép, ESI Juli@ hangkártyával. A gépben 3,3 GHz-es Intel i5 processzor és 8GB RAM található. További berendezések: Akai EWI-USB wind controller, valamint egy Behringer BCF 2000 midi controller.

Mivel az OpenBSD nem real-time OS, aki ilyen felhasználásra szeretné bevetni, érdemes egy-két dolgot észben tartania. Például multiprocesszoros kernel (MP) helyett érdemes egyprocesszoros (SP) kernelt használni, érdemes elegendő CPU-t hagyni a szintetizátoroknak (pl. mellőzni a kernelfordítást és egyéb hasonló tevékenységeket a koncert alatt) stb.

További hasznos tippek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

:D Ez a NAPI TUTI

"mellőzni a kernelfordítást és egyéb hasonló tevékenységeket a koncert alatt"

+1 :)
- - - - - - - - - - - -
Magyar égre, magyar ufót.
300hsz feletti topicot nem olvasok.

Pedig akár lehetne az a zeneszám, ahogyan fordul a kernel. Mondjuk az éppen fordított fájl neve meghatározná a hangmagasságot, az adott fájl fordítási ideje pedig a hang megszólaltatásának idejét. (És akkor ha épp pcc-vel fordítanak kernelt, akkor 20 perces a zeneszám, ha gcc-vel, akkor másfél órás). És máris igazából lenne értelme a multiprocesszoros kernel hasznlatának, meg lehetne párhuzamosan fordítani a kernelt, és így akár többszólamú zenét lejászani.

(Az ötlet amúgy nem az enyém, én csak továbbgondoltam. Már Boris Vian megírta a zseniális Tajtékos napok-ban, igaz, ő koktélt kevert a lejátszott zene függvényében.)

make > /dev/dsp :)

ebben itt nekem az a kérdés, hogy lehet kis overheaddel előtétet/wrappert csinálni a CC-nek . Legegyszerűbb regy 5soros sh, ami valahova logozza, hogy milyen paraméterekkel lett meghívva a CC és mettől meddig futott. Azt gondolom, hogy minden CC session előtt forkolni egy akármilyen shellt az nem lesz túl gyors. Akkor már egy pársoros bináris wrapper?
Illetve kell még 1 valami mapper, ami a forrásfájl alapján eldönti, hog milyen hang szóljon.
Mindezek alapján nehéz azt gondolnom, hogy valós időben értékelhető hangot lehetne előállítani.
Mondjuk én úgy mennék,h ha elindul egy CC példány, az legyen egy midi note on üzenet, ha leáll, akkor egy midi note off. Gyakorlatilag egy szekvencert csinálunk.

6 ms latency azért nem rossz. Nálam olyan 20 körül lehet win-en is linuxon is. Egy low-end hangkártyám van ami kb ennyit tud csak, meg egy i3 -as proci. Hát érzetre azért akár fel is tűnhet a különbség - persze ezt csak a zenész veszi észre, a hallgatóság egyáltalán nem.
Igazából nem tudom, h OpenBSD hogy áll az ilyen multimédia/audio dolgokkal. Most ez a koncert azt akarná jelezni, h ráerősítenek erre a vonalra?

Ha nem egy alaplapi kártyával dolgozol, hanem egy profibb eszközzel, akkor semmi csoda nincs a 6ms-ban. Anno egy mezei SB Live + Asio driverrel 12ms tök átlagosnak minősült. Egy Tascam US-122 MK1 is volt anno az arzenálunkban (ez lehetett vagy 10+ éve), azzal is simán 7-8ms volt a késés.

Hát a mezei hangkártyával való próbálkozás után úgy találtam, h azok használhatatlanok erre a célra, és mindenképp low-latency kártyát kell venni. Így lett egy USB-s Behringer :) kártya, amit viszonylag olcsón be lehet szerezni és megy Linuxszal is. Linuxon viszont Wine-nal futnak azok a programok amiket használnék, és sajna a Jack is borzasztóan instabil volt ezért végül maradt kényszerből a Windows platformnak.

Ez megmagyarázza a nickedet :D
Gondolom akkor Cubase, Ableton és egyéb ASIO-s és VST-s nyalánkságok.

Miért jobb egy processzoros kernelt használni?

MP kernels have issues with interrupts (interrupt handler
may spin waiting for the kernel_lock held by a process). Use
a SP kernel for now.

Kösz.