Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - redustin

Stran: [1] 2 3 ... 23
1
Vývoj / Re:Java DataInputStream - rychlost
« kdy: 21. 05. 2023, 11:28:24 »
Koukám do JDK:

DataInputStream.readFloat() volá interně DataInputStream.readInt, který 4x po sobě volá in.read() po bajtu, kde in je v tvém případě ten BufferedInputStream.

DataInputStream.read(bytes) to předává in.read(bytes), přičemž BufferInputStream.read(bytes, offset, len) volá svůj privátní read1(), která používá System.arraycopy().

Možná v tom je ten rozdíl.


2
Jj, to možná bude parametr --demuxer-max-back-bytes https://github.com/mpv-player/mpv/blob/master/DOCS/man/options.rst


3
Samozřejmě by to šlo také zařídit přes standardní roury  do arecord a příkaz tee, ale má to mouchy.

Z hloupého bajtstreamu není patrno, kde začíná audioframe, takže pokud se rozhodí synchronizace se začátkem streamu, už se neobnoví. Gstreamer si interně samozřejmě posílá správně zarovnané pakety, takže nic takového nehrozí.

Jako player do roury by to stejně chtělo něco, co dělá adaptivní resampling mezi příchozím streamem a hodinami zvukovky. gstreamer/mplayer/asi mpd by to měly umět, všechny umí výstup přímo do stdout.

Ale i tak jsou roury + tee čuňárna, korektní řešení je napojit se do nějaké pipeliny zpracovávající audiostream (gstreamer, ale asi by to šlo i přes pipewire nebo pulseaudio). Vlastní nahrávadlo, které kešuje x sekund audia a nahraje to na disk do korektního formátu (aspoň wav, lepší flac), asi bude nutné napsat. Jak jsem již zmínil, v pythonu by to nemělo být nic zásadně složitého, na vše z toho jsou knihovny a ukázky.

Možná nakonfigurovat odbočku v pipewire/pulseaudiu a nahrávat v pythonu z ní by nemuselo byt tak složité, jako gst v pythonu (s tím jsem musel docela divoce laborovat, dokumentace detailů je spíše formou mailinglistu gstreameru :-) ).

4
Cache v mpv/mplayeru by měla fungovat jako buffer mezi vstupem a processingem. Takže pokud bych v ní chtěl držet 90 sekund, předpokládám, že bych musel stream rádia (který má rychlost omezenou na bitrate) přehrávat s odpovídajícím zpožděním, aby se do keše těch 90 sekund nejdříve načetlo.

IMO by to mělo fungovat tak, že se kešuje posledních 90 sekund bokem, mimo hlavní pipelinu.

5
Určitě to půjde nějak přes gstreamer (např. element tee). U složitejší pipeliny bývá snazší napíchnout se do ní přes python a Gst a odladit si to pohodlně debuggerem a breakpointy v IDE (např. PyCharmu) - zde např. ukázka nahrávání https://github.com/GStreamer/gst-python/tree/master/examples

6
Hardware / Re:HP ML150 Gen9: aktualizace BIOSu a větráky
« kdy: 28. 02. 2023, 13:28:32 »
Trochu offtopic ale možná ne tak úplně moc. Hledal jsem tichý spolehlivý 24/7 stroj s rozumným výkonem vs. rozumnou spotřebou a dostatkem PCI-e slotů pro NVMe do kanclu, kde vedle něj budou sedět lidi. Koukal jsem právě na ML150 G9, ale narazil jsem na to varování o 100% ventilátorech s non-HP disky, nepřichází v úvahu.

Nakonec jsem vzal FS Celsius M740 za pár tisíc z ebay.de se 6-core E5-1650 v4 a 32GB DDR4 ECC, dokoupil opět za pár tisíc 4x 16GB DDR4 ECC (deská má 8 slotů, 256GB max). 10 onboard SATA portů, bytelná bedna, kvalitní zdroj. S 3x 3.5" HDD (dva v předních hot-swap slotech a jeden v SATA hotswap šuplíku pro zálohování ZFS send/receive) na velká data + 2x NVMe na rychlá data žere 65W naprázdno a cca 140W při stress -c 6. Je to takřka úplně tiché, nejhlučnější mi přijde seek HDD disků. Pokud by měl někdo podobné potřeby, mohu jen doporučit.

7
Hardware / Re:HP ML150 Gen9: aktualizace BIOSu a větráky
« kdy: 27. 02. 2023, 16:42:43 »
Pokud se osadí nějaká HPčkem neschválená karta, jdou větráky rovnou na 100%.

To samé jsem četl o discích v HP ML150. S HP disky údajně umí být poměrně potiché, ale s jiným výrobcem jedou ventilátory naplno.

Citace
HPE fakt na bastlení moc není.

Není. Ale překvapivě některé jejich diskové klece mají standardní interní SFF konektory a fungují s běžnými LSI SAS řadiči. Takže např. DL580 Gen7 s 8x SAS lze přehodit kabely na 4x SAS do interního SmartArray pro OS/boot a 4xSAS/SATA do PCIe LSI HBA, do kterých lze nastrkat třeba SATA SSDs pro DB. Dokonce fungují i status ledky. To samé Gen5 s 2 x 8bay klecemi, ale tam myslím status nefungoval.

8
Vývoj / Re:Ovládání přehrávače zvuku
« kdy: 16. 12. 2022, 11:36:01 »
Pokud by se ti líbil ten Peppy, další vlákno je https://www.diyaudio.com/community/threads/peppy-player.288412/ (chce to registraci). Autor výborně komunikuje a kromě programování má dobrý cit pro grafiku.

Akorát je to jen pro RPi.

Jinak klasika pro RPi je moode https://moodeaudio.org/ , ale ten není tak zaměřený na HW možnosti RPi.

9
Vývoj / Re:Ovládání přehrávače zvuku
« kdy: 15. 12. 2022, 23:04:44 »
Pokud bys chtěl již hotové řešení, doporučil bych https://forums.raspberrypi.com/viewtopic.php?t=139983

https://github.com/project-owner/Peppy

Jinak rozumné ovládací API má třeba mpd či mplayer/mpv

10
Server / Re:Snapshot aktuálního stavu v MariaDB
« kdy: 27. 11. 2022, 14:06:01 »
Případně mariabackup (fork xtrabackup od Percony, ten mi funguje velice pěkně). Ale pokud lze DB shodit, je nejjednodušší/nejrychlejší nakopírovat rovnou soubory.

12
Sítě / Re:Pasivní Wi-Fi repeater na 5km spoj
« kdy: 11. 11. 2022, 08:42:42 »
A co tu wifi krmit z pár autobaterií a ty baterky dobíjet benzínovým generátorem? Jednou za den si tam dojdeš nalít trochu benzínu, nastartuješ, a necháš to být.

Kdyby za mnou s takovým návrhem přišel soused, asi bych s tím nebyl úplně v pohodě :-)

13
Distribuce / Re:Java na Raspbian Bullseye
« kdy: 10. 11. 2022, 08:56:44 »
Odtud by to mohlo fungovat (v rámci non-commercial licence)
https://www.oracle.com/java/technologies/downloads/#java8

14
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 09. 11. 2022, 09:01:53 »
Spoustu teorie, ale moc jsem tu nenašel praktické zkušenosti.

Mně Rust vyhovuje, protože lze s minimálním úsilím vyvíjet multiplatformní řešení. Instalace kompilačního prostředí je o stažení jedné binárky z netu (rustup) a jejím spuštění, na všech podporovaných platformách. Aktualizace na novou verzi rustu - opět jeden příkaz. Výsledné binárky jsou velice svižné, nemají problémy s latencí (bez GC), velice snadno přenositelné mezi platformami. Debug je plný užitečných kontrol, po vychytání problémů stačí přidat "--release" a mám několikanásobně menší binárku plnou optimalizací, která běží výkonově i paměťově úsporně, srovnatelně s Cečkem.

Vývoj je velice pohodlný a úplně stejný ve win i v linuxu - stáhnout Intellij Community version a dokliknout Rust plugin. Plugin se drží aktuálního vývoje jazyka, nová verze každých pár dnů. Idea/plugin vše naindexuje, prokliky metod externích crates vedou rovnou do jejich zdrojáků. Zobrazování chyb rovnou při psaní je zrovna v Rustu hodně užitečné, obzvláště pro poučeného začátečníka jako já.  Vývoj je nesrovnatelně rychlejší, než čekat, až s čím přijde kompilátor. Sice v community verzi nefungují v rustu breakpointy, ale to není tak velká překážka.

Snadno mohu zdrojáky crate naklonovat do vedlejšího adresáře a upravovat ji současně s mím projektem v jednom prostředí, pokud něco v nich potřebuji upravit, atd. Vyleze mi opět jedna binárka, a pokud autor crate akceptuje mé změny (typicky zveřejnění užitečných fieldů v public struktech) a vydá novou verzi, stačí v cargo.toml přehodit dependency změnit  jeden řádek na novou upstream verzi. V kompilaci nemusím měnit nic, vše se děje automaticky na pozadí.

Pro SBC/ARM si vyvinu/zkompiluji pohodlně v IDE na mnohojádrové pracovní stanici s několika velkými monitory, cross-zkompiluji do arm64 a stačí přes scp překopírovat binárku na RPi, která by se jinak při kompilaci pořádně zapotila a já předopoval kafem.

Narozdíl od C mám k dispozici pohodlnou paletu hotových struktur, pohodlí téměř jako v javě (hashmapy, hashsety, kanály mezi vlákny všech možných vlastností), dobře vyřešenou podporu chyb s minimální režií, pořádné enumy.

Kompilátor mě nutí psát přehlednější kód. Když srovnám první verzi a verzi po delším boji akceptovanou kompilátorem, snad vždycky je výsledek čistější, logičtější, méně zašmodrchaný, se správně vyřešeným vlastnictvím, atd. Obvykle si po vyřešení konkrétní stížnosti kompilátoru říkám - no jo, takhle to dává smysl, proč jsem to tak neudělal rovnou... Jsou i výjimky, kdy je zkompilovatelný kód více "přes ruku", ale s každou verzi rustu jich ubývá.

Programy napsané v rustu bych v C nikdy nenapsal, protože bych neuměl tak pečlivě hlídat paměť a hodně dlouho bych lovil segfaulty. V Rustu to po první úspěšné kompilaci funguje na 90%, i složitější programy s více vlákny.

Ve win jsem nikdy neprogramoval a s rustem jsem si troufl na javasound nativní DLL pro WASAPI Exclusive https://github.com/pavhofman/csjsound-wasapi . Je tam samozřejmě SPOUSTU prostoru ke zlepšování, ale bez rustu bych na windowsí DLL ani nepomyslel, v C/C++ jsem systémové věci ve windowsech nikdy nedělal, nevím ani v čem bych ten kód psal.

15
Sítě / Re:Pasivní Wi-Fi repeater na 5km spoj
« kdy: 09. 11. 2022, 08:05:21 »
I když bude první spoj úzce směrový, kolik energie z původního vysílání se zachytí v nějaké yagině či rozumně velké parabole a s jakou ztrátou se přepošle v novém směru? 5km je netriviální vzdálenost pro wifi i na přímou linku. IMO to pasivně fungovat nebude. Nakonec pokud bys znal parametry všech antén, asi by někdo uměl spočítat celkový přenos.

Stran: [1] 2 3 ... 23