Poslední příspěvky

Stran: 1 2 [3] 4 5 ... 10
21
Software / Re:Pokročilejší XML browser
« Poslední příspěvek od rooobertek kdy Dnes v 07:58:16 »
Ďakujem za tipy. Pri tej cene radšej zostanem pri troške javascriptu :D Nepotrebujem to zas tak často, aby sa mi to oplatilo.

Na túto možnosť som aj zabudol, ale v browseroch sa dá vo firebugu/developer tools napísať do konzoly document.querySelector("nieco"), vo výsledku sa pohrabať a pravým tlačítkom sa dostanem ku Copy -> XPath. Akurát vo Firefoxe to je o jeden krok navyše - "Reveal in Inspector".
22
Bazar / Re:Predám DDR4 RAM 2x Patriot Viper RGB 8 GB 3.200 MHz CL16 (kit)
« Poslední příspěvek od prodejgrafik kdy Dnes v 07:55:08 »
Prodáno.
23
Studium a uplatnění / Re:Kniha o C či C++
« Poslední příspěvek od echo_zulu kdy Dnes v 07:06:44 »
Z kníh by som začal asi priamo u zdroja: https://www.stroustrup.com/tour3.html, je to taký prehľad, toto vydanie som nečítal, ale to prvé bolo predstavením toho, čo sa volá moderné C++ a ukazovalo písanie kódu jednoduchším spôsobom. Myslím, že táto bude mať ešte viac zjednodušení.

Vývoj C++ ako jazyka a knižníc ide v smere hľadania lepších abstrakcií, ktoré nahradzujú tie, ktoré sú považované za nebezpečné alebo náročné na pochopenie, dokonca tie pôvodné techniky už nie sú odporúčané na bežné písanie, skôr sa od nich systematicky odradzuje.

Ďalší smer vo vývoji jazykov všeobecne je, že k sebe konvergujú, takže aj do C++ preniká funkcionálne programovanie, aj keď to je tam v rôznych úrovniach a do istej miery už odvtedy, čo Stepanov uviedol STL a odvtedy, čo, už neviem kto, šokoval ostatných, keď zistil, že šablóny sú vlastne samostatný funkcionálny jazyk.

Potom ešte existujú oficiálne odporúčania ako písať kód, sú spravované kľúčovými členmi normalizačnej komisie (C++ má normu v rámci ISO), to je na https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines. Je to skvelý zdroj Informácií organizovaný podľa jednotlivých tém.

A potom ešte stojí za to sledovať konferencie, najznámejšia je tu: https://m.youtube.com/@CppCon.

Tu je napríklad sumarizácia toho kam C++ smeruje a aké rozšírenia možností a zjednodušenia práce to prinesie: https://m.youtube.com/watch?v=FNi1-x4pojs
24
Sítě / Re:WireGuard pro domácí síť
« Poslední příspěvek od CFM kdy Dnes v 07:06:24 »
Přemýšlím co je cílem např v případě TV? Aby ostatní na stejné WiFi neviděli, co TV posílá? Pokud je to tolik důležité a nejde nainstalovat WG klient, tak ji vytvoř vlastní virtuální AP/SSID s jiným heslem.
25
Sítě / Re:WireGuard pro domácí síť
« Poslední příspěvek od Pentheus kdy Dnes v 05:13:58 »
michaelscz // přesně takhle to používám teď a problém mám s TV co zmiňuje k3dAR.
26
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od Michal Šmucr kdy Dnes v 02:10:50 »
Tak ještě další věci.
Teď jsem si všiml, že v předchozím příspěvku jsem psal o tom povolení sysrq a cifsFYI přes sysfs.. To jsem omylem zkopíroval z historie terminálu, kde to bylo pro ukecanější debug přes dmesg, což by to info o spojeních v DebugData nemělo být třeba, pardon.
Dělal ještě test s víc jádry, resp cifs moduly.
U 5.15 a CIFS modulem 2.33 (Oracle UEK) to chodí přes jednu síťovku jak pro čtení, tak i zápis.
To, co jsem psal předtím, že zápis využije obě síťovky, fungovalo s kernelem 5.11 a CIFS modulem 2.50 (jak Oracle UEK Next, tak OpenSUSE Tubmleweed).
27
Studium a uplatnění / Re:Kniha o C či C++
« Poslední příspěvek od František Ryšánek kdy Dnes v 00:29:43 »
Knihy mého mládí jsou dnes do jisté míry zastaralé. Mám na ně ale hezké vzpomínky :-)

Třeba Beginning Linux Programming. Nakousne spoustu témat, ale tak akorát, aby se člověk zakousl a dál už študoval po svém / jinde. Třeba kapitola o libpthread (vláknové synchronizaci) je ve skutečnosti velice "nekompletní" - tehdy mi dost pomohl článek na Linuxových novinách (linux.cz) který dnes už nenajdu ani skrz wayback machine... škoda. Ta kniha má kapitoly o všem možném, doporučuji.

Další byla Thinking in C++ od Bruce Eckela. Bejvala zadarmo na mindview.com, dneska se válí kopie různě po webu. Volume 1 základy, Volume 2 "pokročilá" témata. Volume 2 jsem nedočetl - přišlo mi, že jsem u konce s dechem buď já, nebo možná autor :-) Hlavně to co byla před 25 lety pokročilá témata, to je dnes buď dětská hra, nebo bizardní slepá vývojová větev. Navíc mi ve zpětném ohledu připadá, že ta kniha byla sice čtivá, ale ne úplně systematická... A některá tehdejší dogmata se rozplynula jak pára nad hrncem apod. Některé věci se změnily, hlavně do standardní knihovny přibývají užitečné objekty, které si dřív člověk musel obstarat po svém. V dnešní době dost užitečný zdroj aktuálních informací je cppreference.com (online referenční příručka standardního C++, prakticky každé heslo končí examplem).

Ohledně posixových vláken a synchronizačních primitiv mám pocit, že se nedávno dostala prakticky nastojato do standardu C++, akorát už se jim neříká libpthread :-) Je to maličko komické ve světě Windows, kde komunikace mezi vlákny vypadá v rámci WinAPI nativně dost jinak.

A nakonec, čtivé bylo už evangelium podle Briana a Dennise: The C Programming Language (Kernighan and Ritchie). I tady se za těch cca 40 let tu a tam něco změnilo, ale ne natolik, aby starému textu nebylo rozumět :-)
28
Hardware / Re:Zvuková karta pro Linux
« Poslední příspěvek od Marvin kdy Dnes v 00:27:26 »
Převodník USB->TOSLINK (optický) od chiňana stojí pár $$$, některé umí i 24bit/192kHz.
S/PDIF výstup na RCA (koax) by měl mít oddělovací pulsní transformátorek, ale často bývá ušetřen a zemní smyčka zůstává.
Jako USB zařízení to musí mít ve frontě vzorky na milisekundy, aby to stále mělo co vysílat, nějakou latenci to přidává.
29
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od Michal Šmucr kdy 21. 11. 2024, 23:53:40 »
V poslední době jsem neměl moc potřebu tohle řešit, protože jsem používal buď rychlejší rozhraní nebo bonding (a víc klientů), ale je to zajímavé.

Zkusil jsem si to nasimulovat a musím říct, že se to chová dost specificky.
Pokus jsem dělal jen teď na QEMU/KVM virtuálu, kde jsem pak zalimitoval rychlost dvou síťovek na fyzický počítač (který byl zároveň CIFS klientem) na cca 1Gbit.
SMB multichannel připojení se povedlo.
Pro jistotu jsem to ověřil přes

echo 1 >/proc/sys/kernel/sysrq
echo 1 >/proc/fs/cifs/cifsFYI

cat /proc/fs/cifs/DebugData

...kde pak bylo následující:

   Server interfaces: 2   Last updated: 570 seconds ago
   1)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.240
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

   2)   Speed: Unknown
      Capabilities: None
      IPv4: 192.168.202.134
      Weight (cur,total): (1,1)
      Allocated channels: 1
      [CONNECTED]

Při čtení ze serveru to pak jelo pokaždé pouze přes adresu a síťovku, kterou jsem použil při připojování CIFS sdílené složky (tedy v mém případě první).
Ať jsem nastavoval, co chtěl, měnil způsoby čtení (iodepth, vlákna..), zkoušel různé nastavení SAMBY na serveru atp.
Monitoroval jsem na serveru i device statistiku přes sar (ze sysstatu) a data šla vždy jen přes jednu síťovku.

Ano podle toho by se zdálo, že to opravdu nefunguje (minimálně na agregaci rychlosti, failover jsem nezkoušel)
Nicméně pak jsem testoval zápis.
Pokud to bylo jednovláknový zápis s iodepth=1 (nebo třeba jednoduchý zápis z urandom přes dd), tak se to chovalo úplně stejně jako čtení - vše přes první síť.
Ale když jsem zvedl iodepth třeba na 4, nebo na server zapisoval víc souborů naráz, tak to vysaturovalo obě linky na max.
I při kopírování souboru v Nautilu (GNOME) na server to šlo v pohodě až na 220MB/s - kopírování tady evidentně také naplní delší frontu IO operací a ty pak jedou přes obě spojení/adresy.

Takže v tomhle testovacím prostředí to vypadá, že multichannel smysl má i z Linuxového CIFS klienta, ale jen pro zápis.

Možná by na to čtení teoreticky mohlo mít vliv i to, že mám s těmi virtuály specifickou topologii sítě s bridgem a pokud bych to opakoval třeba na dvou fyz. počítačích, kdy by měl každý dvě fyz. síťovky, tak by se to mohlo chovat odlišně.. Ale moc bych na to nesázel. Plus jsem dělal teď jen rychlý test, nehledal jsem nikde ve fórech, mailing listech atp.
30
Hardware / Re:Zvuková karta pro Linux
« Poslední příspěvek od František Ryšánek kdy 21. 11. 2024, 23:28:13 »
Pokračuji v debatě už notně off topic a trochu se za to stydím:

...
Jenom mi vrtá hlavou, proč výrobci desek nepřipojí zem zvukovky/USB portu odděleně přes jeden/více GND pinů/kabelů ATX konektoru, aby se to spojilo až v tom proletovaném hnízdě v PSU, kam vede i PE vodič. Ale možná to někteří tak dělají, netuším.

Pochybuju :-)
Mimochodem by se pak na motherboardu musela nějak "izolovaně překračovat" analogová vs. digitální zem, mezi kterými by se hemžilo všechno možné od DC po pár MHz (v desítkách milivoltů, pokud ne víc).
A stejně by to nebylo dokonalé z hlediska odrušení té "samostatně vedené analogové země", protože by byla částečně v souběhu s tou pracovní zemí silovou, takže by se tam ledacos indukovalo skrz magnetické pole...

Ani řešení pomocí symetrického analogového vstupu neztlumí rušení úplně do nuly, protože CMRR je konečné číslo. Jasně, může to pomoct docela dost, zejm. pokud to rušení nejde moc vysoko nad akustické pásmo (aby to vstup "stíhal odčítat", aby mu na to stačila šířka pásma / rychlost přeběhu). Na 50Hz brum to stačí s velkým přehledem.
Tímto nechci tvrdit, že jsme ve sporu :-) Sám jste zmínil galvanické oddělení, což je i moje oblíbená metoda řešení zemních smyček.

Citace
Citace
Pravda je, že USB má i v "interruptovém" přenosovém režimu de facto periodický polling v taktu 1 ms, plus tam budou nějaké buffery (=latence) takže "ten můj USB dongle" v tomhle ohledu není dokonalý, 

Tak dražší profi USB zvukovky používají highspeed bInterval i 125us, což je úplně v pohodě. Samozřejmě USB MIDI dongle pojede na lowspeed, tudíž min. 1ms již na připojení. Na druhou stranu i ta PCI zvukovka má nějakou latenci obsluhy přerušení...

Díky za dovzdělání, tohle mi unikalo :-) Jestli správně chápu, granularita 125us je vlastnost highspeed fyzické vrstvy? Oproti fullspeed, kde je natvrdo 1 ms. A bInterval je celočíselný násobek tohoto vrozeného kvanta.

Citace
Citace
Co se týče čistoty výstupu a šířky pásma k basům, stojím si za tím že ten konkrétní model generického USB donglu co jsem uvedl, se 24bit DAC/ADC, není vůbec marnej, i ve srovnání se svým hloupějším 16bitovým bráchou (vypadá stejně, jenom nemá v obj.kódu "HQ").

Máš prosím konkrétní link?

Jasně: 1) Axagon chytřejší dražší brácha, 2) Axagon hloupější levnější brácha.

Já mám toho dražšího, a moje hodnocení je pohříchu subjektivní. Měřit tomu zkreslení a šum jsem nezkoušel, mj. protože nemám čím (leda smyčkou).

Zkusím přiložit .TXT dump lsusb -v. Říká, že výrobcem čipu je VIA, a že fyzická vrstva je USB 1.1. Ona je to možná přesněji "USB 2.0 na full-speed rychlosti" :-) což je prakticky totéž. V tom případě pro mě platí ta 1 ms.

Když jsem zkoušel googlit USB PID 0x3417, našel jsem kdesi zmínku, že dotyčný čip je VT1620A. Parametrově by to vcelku odpovídalo. A tenhle šváb je skutečně jenom USB full-speed.

Google mi našel taky (pěkně uleželý) paperlaunch čipu VIA Envy VT1730, který byl údajně jako jeden z prvních high-speed. Ale nedaří se mi, nalézt s ním nějaké produkty.

Citace
Citace
Pokud tam bude na výstupu zes ve třídě D, tak bych moc neřešil, jestli je DAC 16b nebo 24b,

Jenom k těm D - dneska už se to hodně posunulo. Takové TPA335x 100+ W za 40USD včetně bedny má velice slušné parametry, i ty superlevné TPA3116 minikrabičky hrají velice slušně (mám jich doma několik).

Heh taky mám jednu čínskou destičku s TPA3116. Zkoušel jsem s ní budit takové sranda bedničky osazené Visaton BG-20-8, a jako zdroj signálu právě tenhle zmíněný USB dongle. Šumělo to relativně slyšitelně, třeba z podání vyššího konce pásma jsem taky nebyl úplně odvařenej... ale fakt je, že jsem nad tím mávnul rukou a třeba napájecí zdroje jsem nezkoumal. Po téhle Vaší recenzi se k tomu myslím ještě vrátím :-)
Do sluchátek ten USB dongle nešumí.

Citace
A moderní Dčka ve zkreslení při výkonu a celkové vychovanosti v zátěži už jasně nad lineáry vedou, viz např. https://www.audiosciencereview.com/forum/index.php?threads/purifi-eval2-eigentakt-mono-amplifier-kit.54938/

:-O

Citace
Citace
Pokud se týče výstupu do zesu, ještě bych zmínil, že existuje optický digitální propoj TOSLINK resp. S/PDIF. Je to sice spíš záležitost spotřební elektroniky než profi audia, ale zemní smyčku to přeruší. Nemám představu, jestli to třeba nepřidává nějakou latenci.

Latence bych se asi nebál, vysílač bude mít téměř nulovou, přijímač např. DIR9001 uvádí latenci 3 vzorky, tedy nic.

To nezní marně! Akorát... vytáhnout z počítače S/PDIF výstup znamená buď začít motherboardem (okolo 3kKč už se najdou s S/PDIF výstupem) nebo přidat soundblaster s tímhle výstupem, a co pak s tím dál: buď převést levným DAC donglem za pár šupů na analog (a dát si pozor na země a napájení), nebo koupit receiver okolo 10 kKč jenom abych měl zes nativně s tímhle vstupem...

Jinak - 50Hz železné trafo má velkou výhodu, že neprodukuje VF rušení.
Jakýkoli spínaný měnič/adaptér, klidně ve třídě II a "medical grade", má slabý průsak (směs 50 Hz a VF). Pár desítek až stovek mikroampérů. Pokud by byl zájem o medical-grade napájecí adaptér, a dalo by se to zpřevodovat konektorově (a skladbou výstupů), tak tyto jsou k nalezení v TME, k dispozici je filtr "použití: pro lékařské aplikace". Zde k tématu jsou relevantní nejspíš kategorie stolní napájecí zdroje (formát "notebooková cihlička") nebo adaptéry do zásuvky.
Stran: 1 2 [3] 4 5 ... 10