Egyrészt bocsánat, mert nem *nix környezetről lesz szó.
Másrészt hogy kerül a hangkártyához CPU? ;) Mindjárt kiderül!.
16 éven át használtam nagy megelégedéssel egy M-Audio Firewire Audiophile interfészt. Ezt a linux természetesen nem támogatja. (az ffado nevetséges) Sajnos Win 10 drivere sincs, ezért némi trükkel felraktam a Win 7 64 bites drivert, ami ASIO-n keresztül hibátlanul működik, de a Windows nem tudja kezelni a sample rate-et.
Úgy gondoltam, hogy az M-Audio jó, ezért vettem egy Air 192|8-at. Tévedtem. Sajnos a beüzemelés nem járt sikerrel. A hang "indulása" mintha két lépésben felkevertem volna, recsegett-ropogott. Pl, a foobar2000 album list-en vagy a firefox könyvjelző ikonokon végighúzva az egeret (hover) is ropogás keletkezett. Néha a szám elindítása közben moccantva az egeret lefagyott a driver, akár ASIO-n akár Windowson keresztül hajtottam. Az alábbi ábra a Windows hangszóró teszt: bal-jobb az Air-en keresztül, masjd egy működő hangeszközön keresztül (UA Volt2).
Úgy érzem, a két minta kissé eltér. :-D A forgalmazó support szerint "Az biztos, hogy ez egy hibás hangkártya szerintem, de majd megmondja a szerviz."
Egy csomó rigorózus beállíotást megtettem az usb hangeszköz kifogástalan működése érdekébem, még az egeret is vezetékessé alakítottam, hátha a vevője okozza a zavart, de a siker elmaradt.
A rendszer:
- Windows 10 Enterprise N LTSC 21H2 19044.5011
- AMD Ryzen 3 4300G with Radeon Graphics 3.80 GHz
- B550 GAMING GEN3
Az internert népe szerint ez a cucc nem megy AMD-vel, mníg egyesek probléma nélkül használják. Jómagam végigpróbáltam a CPU-USB3, B550-USB2 és egy kínai USB3 pcie kártya portokat is. Az utóbbinak nem lenne szabad függenie as CPU-tól. És egy kolléga kipróbálta Intel CPU-val és neki kifogástalanul működött!
Ki üti le a magas labdát? Mi a különbség az Intel és AMD CPU-k között?
A végeredmény egy Focusrite Scarlett 4i4 3rd gen lett. Ezzel teljesen elégedett vagyok. Egyrészt a Focusrite szinte IBM-szintű dokumentáció biztosít, valamint deklaráltan Intel/AMD drivert biztosít. A kevererő szoftverük sem rossz (Focusrite Control) - még a szemem is könnybe lábadt, amikor olvastam a routing szót a dokumentációban. ;) Eközben az M-Audio nem biztosított keverőt a kütyüjéhez - amit nagyon megszoktam a Firewire szerkezettel. Ott volt AUX Bus, itt meg loopback, ami néha nagyon hasznos tud lenni, bár talán egy jack helyettesítheti mendkettőt, de tisztább szárazabb érzés, ha nem kell használni.
Hozzászólások
Nem tudom, hogy most komoly vagy, vagy csak trollkodsz. A következetes „Inttel” írásmódból ítélve gondolom, hogy csak parodizálsz.
Természetesen semmi köze nincs a CPU-nak a hangkártyához. A kollégádnak nem azért működik, mert Intel CPU-ja van, hanem valami szoftveres körítés lehet más neki. Tippre nálad az N-es Windows bonyolít, abból a verzióból kiszedtek egy csomó multimédiás cuccot, ami kellhet a hangkártya driverének. Alapszabály, hogy ha nagyon nem muszáj, akkor desktopnak hanyagoljuk az N-es Windowst, csak a szopás lesz vele, kb. 0 nyereségért cserében.
A Scarlett 4i4 gentől függetlenül egy jó választás, nem csak elfogadhatóan szól, de az egyik létező legkompatibilisebb cucc, nem csak Win10-zel, hanem Linux alatt is normálisan támogatott, nem úgy, mint ilyen kisebb cégek terméke, mint az M-Audio.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Trollkodok -> vaksi is vagyok, meg most vagyok túl egy napi 700 kcal diétán és még nem tértem magamhoz. ;) Pedig mindig kétszer átolvasom amit írok. Javítottam.
A CPU-nak talán a driverhez van köze. A kollégámnak nem LTSC Win 11-e van. Az N-es Windowsnak meg semmihez semmi köze. Az egy EU balhé után keletkezett még az XP fiatal korában. Attól kezdve ELMÉLETILEG nincs fenn a default browser és média player (stb) és választhatsz mást is. Tizenévig olyan slipstreamelt N-es XP-t használtam, amiből nem csak az előbbi elemek, de az összes beépített codec is hiányzott és alapértelmezetten a Windows Audio Service le volt állítva (XP), míg Win 10-en két ilyen entitás van, talán az input és outputhoz is egy. Ezek nem szükségesek a vlc-hez sem, de különösen nem kellenek a foobar2000-hez (SoundForege, Ableton Live, stb.), mert ezek az ASIO driveren keresztül közvetlenül szólaltatják meg a hangot. Az ASIO drivert a Windows csak futtatja, de nem látja (most így mondom) és nem használja.
Inkább az a lényeg, hogy a Scarlett és a Volt 2 jól működik és az Air meg nem. A pcie kártyában nem AMD CPU/chipset volt.
A "kisebb cég" véleményed teljesen helytálló, mert a Focusrite bármilyen kérdésre és hibára képes precíz működő választ adni.
Sztem olyan nagyon extrán nem tér el a két minta - az egyik hangosabb :D. Ezt az egérmozgatás hangot produkál inkább az alaplapi hangkártyáknál tapasztaltam. Lehet h a Scarlettben van galvanikus leválasztás?
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Nagyon engedékenyen kezeled a dolgokat, miközben a két egymás utáni hang azonos hosszúságú, azonos hangerővel bitre pontosan ugyanaz. Az első némi pöszmötölés után sokkal kisebb hangerővel szólal meg, majd felüvölt, miközben végig torz és recseg.
Legjobb tudomásom szerint nincs galvanikus leválasztás egyikben sem. Bár használtam már galvanikusan leválasztott usb hanginterfészt is, de a leválasztás hiánya legfeljebb enyhe brummot okozhat ebben az esetben, de csak az analóg vezetéken. Az usb kábelen is digitális jel közlekedik.
Az egér zavarást azért tételeztem fel, mert (usb-s műszereket fejlesztek) volt olyan ügyfél, ahol a 12Mb/s interfészt egyértelműen megzavarta valami nagyértékű bluetooth egér. Olyan kísérletet is elvégeztem, hogy távoli hub-ba dugtam a vevőt, vagy vezetékesre alakítottam az egeret (olyan egerem van, amely ezt is tudja) - változás nem volt. Az, hogy az ikonokon végighúzott egér (ikononként hover) recsegést okoz, valami "belső szoftver összeakadásra" utal.
Odaraktam a kép alá egy linket a hanghoz.
Jaaaaaa, pardon - most meg is hallgattam -, én azt hittem h felső sor az egyik hangkártya, az alsó meg a másik jele. Természetesen azt látom, h az egymást követő jelek eltérnek, de felül meg alul ugyan az a minta közelítően. Igen, az Air192 egyértelműen torz és ahogy írod is végig torz, nem csak a hangos résznél. Driver probléma?
Az a tapasztalatom h az USB kábel is átvisz zajokat. Ha az egér megszakításai okoznák a zajt, akkor (felteszem) a többi kártyánál is jelentkezne. Wifi kártya is tud hasonló zajokat generálni, mint az egér. De háát ki tudja, csak ötletel az ember...
Sztem legjobb megoldás optikai csatlakozón és kábelen kiszedni a jelet a pcből és külső DAC-ra kötni. Akkor nincsenek zajok a lejátszásnál.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Az időtengely vízszintes és a fent leírt idősorrendben látod a jeleket. ;)
Az USB 2, akkor 12 vagy 480MHz. A közösmódusú jelek csökkentésére elegendő egy ferrigyöngyös kábel, ami persze az alacson frekvenciákat nem csípi el. Az spdif vagy coax jobb, csak ezen az alaplapon/interfészen nincs ilyen, de zaj sincsen.
Na ez itt a kérdés, hogy a két CPU között mi lehet az a nagy eltérés, mert a driver ezen a szinten nem igazán több egy eseményeket kezelő szoftvernél.
Linuxszal nem tudod kipróbálni azon a gépen? Akkor esetleg kiderülhetne, h hw v. sw probléma!
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Ez eszembe sem jutott, mert a linux csak azt a hardvert támogatja, ami vérpistikének van otthon a kutyaóljában. (Vagy az IBM beletolt néhány millió dollárt.)
Különben is >600GB anyag foobar2000 alá van rendezve és elég régen azt használom.
Mivel két eszköz is kifogástalanul működik, majd a szeviz utánajár.
Én időzítés érzékeny felhasználáshoz csak intelt vennék (de nem a legújabbakat, max 12 gen, de az is necces a big-little miatt). AMD-n (A520/5600g) volt már, hogy a SATA port (amin pont nem volt semmi, csak nem lehetett UEFI-ben tíltani) bezavarta a videó lejátszást, recsegett a hang. Ha Windows alatt le volt tíltva a vezérlő, vagy volt rajta eszköz, megjavult a hang. Hiába jobb a Ryzen proci, ha a körítést nem érzem annyira stabilnak, ami simán lehet annyi, hogy az Intel hülyeségeire sikerült felkészíteni a programokat az AMD-re meg nem teljesen, de eredmény szempontból majdnem mindegy.
Én ezzel a programmal találtam meg a baj forrását:
Download LatencyMon - MajorGeeks
Szerintem egyesek összekeverik a desktop gépekbe szánt CPU-t a mikrokontrollerekkel. Egy desktop CPU sohasem ígérte, hogy valós időben ki fog szolgálni. Megannyi cache, burst-ös adatmozgatás, DMA, IT, és könnyen lehet, ezeket másként csinálja egy Intel és egy AMD architektúra. Ettől még az AMD nem rossz, csak valamelyik hülye úgy tervezte az illető audió rendszert, hogy azt gondolta, kap a CPU-tól valós idejű kiszolgálást. Hát nem kap.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Én azt nem értem, hogy ha nem hangszer effektnek használjuk, vagy kompetitív gamingelünk, akkor mit számít a latency? Meg kell növelni a bufferméretet és kész. Ha viszont nagyobb buffermérettel sem működik stabilan, akkor 99%, hogy szoftver hiba. Tipikus, hogy a szoftveres nem tudja megírni rendesen a drivert és ráfogja a hardverre, hogy szar :-)
A pufferméret eszetlen növelése pont hogy -zavaró mértékű- késleltetés növekedést okoz. Minden létező adatátviteli esetben. Ha picit átgondolod, rájössz magad is.
Abban az esetben igen, ha valaki csak akkor kezd a pufferből olvasni, amikor az már megtelt. Ha viszont akkor, ha a pufferben lévő adat elért egy minimumszintet, akkor a késleltetés nem feltétlenül növekszik a pufferméret növelésekor.
Ha például online rádiót hallgatsz, számít, hogy egy másodperccel később csendül fel a zene, mint amikor azt neked szánták?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
mert, ha offline-t hallgatsz? :D
le a hangfalakkal, fejhallgato, FTW! :D
Attól, hogy hülye volt a fejlesztő, még cseszheted az adott feladatnál, hogy nem azt a rendszert választottad, amin hajlandóak voltak tesztelni a fejlesztők a szutykukat. Én is magyarázhatom az illetőnek, aki mostanában kért segítséget gépet összerakni hasonló feladatra, hogy jó az az AMD, csak épp az ő szutyka nem fog azzal jól menni. Beletörődés helyett inkább Intelt kell vennie (tudom, válasszon másik rögzítőprogramot/rögzítőeszközt, de nem fog)
Én ezt értem, de ez a probléma maszatolása. Mondjuk úgy, Intel architektúrán véletlenül működik, de erre sincs garancia, inkább csak tapasztalat és remény, mert gyanítom, Intelt is lehetne úgy használni, hogy ne menjen vele. Például tegyünk fel arra a gépre egy Apache-ot, indítsunk ellene egy DDoS-t, s nézzük meg, recseg-e a hang közben.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ezt úgy kell érteni, hogy az üresen hagyott SATÁn IRQ-q jöttek, amik a procit késleltették be, vagy elektromos zavart okoztak, ami tönkretette az USB csomagokat a másik vonalon? Vagy mit kell ez alatt érteni? Fejtsd ki, ha van időd, mert érdekes, de nem értem!
Egyébként teljesen más területen láttam olyat, hogy egy nem használt csatlakozóról random időpontokban jöttek események (statikus feltöltődés, vagy elektromos zajérzékenység lehetett az oka), amik IRQ-t okoztak és ráadásul időnként rosszkor jöttek és lefagyasztottak egy gyengébben megírt programot. Le lehetett tiltani a hardvert szoftverből, az lett a megoldása.
Előbbi. Recsegett a hang lejátszásnál. Addig gugliztam, míg rátaláltam a LatencyMon-ra. Az futás közben az egyik mért értéknél kiírta, hogy az AHCI-hoz tartozó sys túl sokáig tököl, miközben semmi nem volt a vezérlőn. Letíltottam az eszközkezelőben, megjavult.
Tehát valakinek sikerült inicializálatlanul hagynia a hardwer-t, de ez sem az Intel, sem az AMD, de még csak nem is az audió rendszer tervezőjének a hibája.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Hogy összegezzem az előttem szólókat is. ;)
Amit írsz az nem is városi legenda, hanem a marhaság szintjét is eléri.
Egyébként:
Ha nem így lenne, azon megdöbbennék. Igaz fw-en keresztül játszottam le 6 csatornás SACD ISO-t, dekódolással, sztereóvá alakítással, de Athlon X2 BE-2400: 2,3 GHz, TDP 45W - XP N SP2 rendszeren. Ez egy 2007-es kiadású K8 proci, valószínűlrg összehasonlíthatatlanul lassabb, mint a Ryzen 3 4300G, 3,8GHz. Az előbbi CPU ilyenkor már izzadt egy kicsit, de semilyen hiba nem volt a lejátszásban. A Focusrite oldalán van egy elég rigorózus hangolási útmutató, aminek 80+%át én is elvégeztem, tehát nem volt ami visszafogja a hangvisszaadást.A teszt felvétel készítésekor 44,1kHz*2*16 bit volt a felbontás, míg az említett 6 csatornánál 5.644.800Hz*1 bit (DSD128). Az utóbbi 4x több bit, csak sokkal nehezebb dekódolni.
A lekapcsolatlan, de használaton kívüli SATA csak memóriát fogyaszt.
Ha ennek bármi értelme lenne, akkor az AMD CPU-k eladhatatlanok lennének. Bármilyen endiánt részesítesz előnyben, mégis mindegy. Ha választanérk, akkor big.
Nekem is volt szerencsém egy Core i3 4 gen-nel szerelt alaplaphoz, ahol a hangszóróból világosan hallatszott az egér report rate és a diszk fejmozgása is. Ebből egyáltalán nerm következik, hogy az Intel szar!
Biztos a CPU-tól függ ez és nem a USB chipset-től? (Ami gyakori, hogy Intel CPU-hoz abból is Intel van a lapon.)
Nekem "Zoom UAC-2"-m van - ami azért nem egy "futottak még" kategória - de USB3-on atomstabilan csak Inteles chipsettel megy, minden más esetben igen hasonló dolgokat produkált, sokat szívtam vele eleinte. Szerintem csak erre tudták rendesen a drivert megírni és kitesztelni.
Zeni fórumokon is erre jutottak a userek, már a gyártó is az Intel chipsetet ajánlja hozzá.
Így nálam ez szempont volt, hogy az USB3-as interface-t Intel chipset adja, nincs is vele semmi gond, 2-3 ms-es latency-vel megy mint az álom, nem reccsen, nem fagy,... (NUC13x mini PC)
Vannak ilyen hiedelmek és tapasztalatok is.;) Ez az, ami ép ésszel fel nem fogható. Az USB nem egy atomfizika.
Van egy low level rész, ami legyen a driver/kernel api, ami kb. ilyenekből áll: küildj egy blokkot, vettem egy blokkot -> event, kapcsolj az X üzemmódra, stb. Ha a csip tudja az USB szabvány ezen részét, akkor a driver is tudja ezeket a funkciókat. A többit a hw végzi a két dróton. A szabványnak van egy másik része, ami már a csatlakoztatott szerkezetről érrkező adatokat értelmezi. A szerkezet pl. azt válaszolja, hogy én megfelelek az USB Audio Class eszköznek és van 2db hangerőszabályzóm, stb. A gyátó drivere azt illeszti az OS-hez, hogy a hangerőszabályzót lehessen piszkálni. Az utóbbi rész jóformán tiszta szoftver.
Na, itt az érdekesség, hogy melyik gyártó csipje nem felel meg a szabványos low level rétegnek, merrt az kb eladhatatlan lenne. A többi meg az előbbi rétegen csereberélt adatokból kiderül. Ezért van az, hogy az USB hangeszközök jó része Windows alatt driver nélkül is részlegesen problémamentesen működik (p. a Volt 2 is), mert az ilyen eszközök kezelése beépített az OS-be. Ami esetleg nem képes felderíteni a teljes routing/mixer topológiát, vagy semmit sem tud az AIR bekapcsolásáról, mert nem szereppel a szabványban. Ez pl. a klasszikus transzformátoros mikrofon illesztés hangképének emulációja megfelelő szűrőkkel. Szóval a gyártói driver hassznája a szabványos kernel api-t és gui-t biztosít a spec topológiához.
Ha a fenti dolgok világosak, akkor az eszköz nem függhet a csip gyártójától, ha az megvalósítja a szabványban leírtakat. Perrsze láttunk már olyat is, hogy két különböző gyártótól származó, ATA szabványt megvalósító diszk nem fér meg egy kábelen. :-D
Hasonló hiedelem, hogy a régebbi eszközöm az M-Audio FW csak Texas csippel működfik együtt, pedig évekig használtam VIA-val. Lehetséges, hogy az információ keletkezésének idején a VIA nem teljesítette maradéktalanul a FW szabványban leírtakat. A másik gyanúm, mivel ez az eszköz bus poweredként is működhet, a Texas más (jobb) technológiával csinálta a leválasztott tápot.
Az USB3 is egy jó kérdés. A Scarlett áramfelvétele 900mA (amit az USB3 tud), der az USB2 hivatalosan csak 500mA-t ad ki és lekapcsolhatja a tápot, ha túlléped. Itt általában nincs gond, mert 10-15 éve (az ájfón töltése óta :-D) Az alaplapok a névlegesnél jóval nagyobb áramot adnak. Pl. a HP monitoromba épített HUB 1600mA töltést biztosít a telefonnak.
Igen, ez emléletileg OK és belátható, de sajnos (nálam biztosan) a gyakorlat mást mutat.
Az előző gépemben alaplapon (Asrock miniPC) 3 féle USB vezérlő volt. (Intel, FrescoLogic,...) Az intellel minden gond nélkül ment ez a hangmodul oda-vissza, a többivel "bohóckodott". (gyári külső tápról is)
De csak ötlet volt, hogy lehet nem kifejezetten a CPU miatt van a probléma, amit tapasztalsz. :-)
"Az USB nem egy atomfizika."
Pedig sajnos a tapasztalatom az, hogy "lelkük van". Van saját firmware-je az USB3 kontrollernek, és tudnak nagyon specifikus, megmagyarázhatatlan hibái lenni. Nekem példám valami NEC kontrolleres PCIe USB3 kártya, talán uPD720200 - most nincs kéznél a gép amiben benne van, hogy meg tudjam nézni.
Egyszerű uasp külső SSD házzal ezen pár másodpercnyi folyamatos olvasás vagy íras után egyszerűen leáll az adatforgalom. Wiresharkkal capture-ölve is annyi látszik, hogy bármi hiba vagy előjel nélkül egyszercsak, mintha elvágták volna, nem megy át több usb packet. Kihúz-bedug kell hozzá, hogy újra működjön.
Ugyanez működik raspberry pi-n, Inteles usb3 vezérlőn, még a tp-link routerem usb3 portján is (lövésem sincs milyen kontroller van benne). A NEC kártya külön belső tápcsatlakozós, 3A-es soft fuse van az usb port előtt, nem tápprobléma.
Fórumokban találtam rá hasonló tapasztalatot, állítólag millió firmware update jött ki rá, nagyon bugos. Persze csak windows-os update utility van, hozzá. Készült valami linuxos is: https://github.com/markusj/upd72020x-load de amikor próbáltam, az enyémet nem támogatta, és lehet hogy nem is fogja.
Szóval én (ahogy páran javasolták) helyedben megnézném hogy az alaplapon melyik port, melyik kontrollerből jön. AMD-nél van usb vezérlő ami a processzor IO die-on van, van az alaplapi chipsetben is. Az alaplapgyártó tehetett még 3rd party usb3 vezérlőt is a lapra. Én végigpróbálnám, lehet, hogy különbözőképpen viselkednek.
Voltak konkrét ismert hibák az AMD-s usb3 implementációval, ezeket - ha még nem tetted -végignézném:
https://www.reddit.com/r/Amd/comments/13yhdup/2023_almost_3_years_later_and_we_still_have_the/
https://www.tomshardware.com/news/amd-suggest-possible-fixes-for-usb-connectivity-issues
Régóta vágyok én, az androidok mezonkincsére már!
Valahol feljebb írtam, hogyy CPU USB3, B550 USB2, kínai pcie USB3 (vindóznak tetsző csip) teszt megvolt. A kolléga Intel+win11-en nem talált problémát. A latency monitor szerint egy Intel alaplaphoz képest az enyém táltos. És nem ez volt az első usb eszköz, amit a gépbe dugtam, de a többivel egyik porton sem volt probléma.
A linkeket elolvasom, aztán mindenkinél is okosabb leszek!
De mi az a kínai kártya? Milyen gyártó IC-je van rajta? Asmedia vagy hogyhívják? Azért kérdezem, mert tudtommal az AMD chipsetjében is Asmedia IP blokk adja az USB-t (citation needed, most nem álltam neki utánakeresni), szóval lehet, hogy nem különbözik olyan nagyon.
Másrészt a kérdés a driver. Elvileg az összes USB3-as vezérlőnek xHCI-t kéne támogatnia. Emiatt lehet, hogy az egész rendszeren az összes USB vezérlő valójában ugyanazt a drivert használja. Namost, ha az AMD platformon valami AMD/Asmedia/kitudjamilyen saját chipset driver fel lett rakva, akkor a default Microsoft-os xHCI driver helyett valószínűleg minden USB-t az vezérel, akár saját gyártmány, akár nem. Intelen gondolom lehet ugyanez a helyzet, csak Intel-féle driverrel.
Még további bonyolítás, hogy a driver on-the-fly betölthet firmware-t az USB vezérlőbe, anélkül, hogy az eeprom-ban lecserélni a perzisztens firmware-t. (Amit linkeltem githubos projektet az NEC vezérlőhöz, az ugyanezt csinálja). Nem tudom, hogy az alaplapon van-e dedikált eeprom-ja, vagy a fő BIOS flashből töltődik be egy dedikált firmware blokk. Az add-on USB kártyáknál szokás, hogy van egy kis SPI eeprom a saját firmware-nek. Ez a "nem perzisztens" firmware update abszolút nem része az xHCI-nek, ezt biztosan proprietary driver csinálja, ha csinálja. Ez megint sunyi eltéréseket okozhat a két gép között, függően attól, hogy pontosan milyen driverek vannak fenn.
Szóval nekem a fő tippem az, hogy - látszólag bármennyire is ellentmond a saját addon kártya viselkedése - valami driver dolog lesz ez és abszolút elképzelhető, hogy az AMD (vagy OEM partnere) a sáros benne.
Régóta vágyok én, az androidok mezonkincsére már!
Ez magyarázatot adhat a kártya hasonló viselkedésére. A csip passz, valószínűleg kínai, de nem említették honnan koppintották. ;)
Ha valahogy meg lehetne oldani, hogy mindkét gépen a Microsoft-os xHCI driver legyen csak fenn... gőzöm nincs róla, hogy egy mai "modern" Windows-ban ez mennyire megcsinálható, ha egyszer már valami gyártó-specifikus rontás felment rá.
Régóta vágyok én, az androidok mezonkincsére már!
Valószínűleg némi szövegszerkesztéssel átverhető lenne a rendszer. Mivel már nincs nálam a szóban forgó eszkoz, nagy bátran felpróbálom az alant említett béta biost. Talán az USB3-as pendrive sebességével tudom detektálni a változást. Azért csak 50%-ig hiszek ebben a javításban, mert szerintem a hiba valahol nem a low level oldalon lehet. Akkor meg hol? :-D
"a hiba valahol nem a low level oldalon lehet. Akkor meg hol?"
Feltételezel egy tiszta ISO-OSI értelemben vett protokoll-rétegszerkezetet. Ami lehet, hogy a specifikáció szintjén még teljesül, de a gyártók meg ott gányolnak ahol csak tudnak. Az USB kontrolleren futó firmware és/vagy az oprendszer szintű driver valószínűleg könyékig turkál a "magasabb rétegbeli" üzenetekben is. Így vannak kioptimalizálva, hogy a gamereknek fontos latency benchmarkban jó eredmény szülessen, közben a pendrive-ok is NVMe SSD-kkel vetekedő átviteli sebességet produkáljanak (persze csak a benchmarkban).
Tudom, kicsit off, de az első hasonló élményem a korai USB pendrive-okkal az volt, hogy egy FAT32-vel hibátlan pendrive, ext2-re (vagy ext3-ra, mindenesetre jó régen volt) formázva blokkhibás volt. Badblocks-szal tesztelve egyértelműen voltak hibás blokkok, ráadásul ide-oda mozgott a helyük (első találkozásom a flash translation layerrel...). FAT32-re visszaformázva megint hibátlan volt. A block device, ami tudja, hogy milyen filerendszer van rajta... Nyilván volt valami specifikus optimalizálás a firmware-ben, aztán nem tesztelték le, hogy mivan ha mégsem a gyári default filerendszer kerül rá.
Ide a rozsdás bökőt, hogy valami ilyesmi baj van itt is. Valami csoda optimalizálás félremegy, mert nem elég "mainstream" a hardvered, hogy össze legyen próbálva vele. Lehet, hogy pont valami proprietary latency-javító prioritizálásnak kerül a rossz végére az audio cucc forgalma.
Nyilván ezeket nagyon melós kinyomozni. Wireshark capture-rel sem biztos, hogy látni fogod a lényeget, vagy ha ki is tudod mutatni a különbséget, az okához nem jutsz közelebb.
Régóta vágyok én, az androidok mezonkincsére már!
Ez elszomorító. A pendrive még érthető (NEM), mert ott egy CPU-t olvasgatsz a flash helyett, amit nem okosítottak fel mindenre. Az oroszoknál biztosan van erre is patch. ;)
A torz hangfelvétel is érdekes. Három különböző szakaszból áll, amelyből az első kettő túl halk és recseg, a harmadik hangereje 0dB-től csökken exponenciálisan, mintha egy számláló tévesen a hangerő vezérlését találta volna el. Hasonlóan nem találja a helyét, mint a badblock. ;) Rádásul ez a Win 10 (igaz Win 7-es driverrel) nem képes beletalálni a másik eszköz sample rate beállításába. Innentől talán nem is a rendszeridegen driver a ludas.
Én fel is adtam AMD-n az előlapi USB használatát, két alaplappal (B450/A520) és két processzorral (3200G/5600G) se volt jó, pedig legalább kétféle ház és egy hátlapi USB kivezetéssel is próbáltam az alaplapi csatlakozót, nem hinném ezután, hogy kábelhiba. Az egyikre még maszek árnyékolást is tettem. Valamiért csak az alaplapról közvetlenül a hátlapra kivezetett csatlakozók jók AMD-n :(
USB2.0-án még valahogy müxik is, de amint USB3 pendrive/HDD nagyobb adatmozgatás mellett, azonnal meghal az átvitel. UEFI/A Géza mindig a legutolsó verzió, ami van a laphoz.
AM4-en (de legalábbis x570 chipset) vagy 2 évig (igen, vagy 24 hónap volt) baszkódott AMD az agesa-kkal, mire állítólag a sorban 7. vagy 8. bios release (ami mind azt állította h. mostaztánmártényleg kijavította az usb hibákat) után már talán a leghangosabb panaszkodók elhallgattak.
A legújabb béta bios egyik fícsöre: AGESA ComboAm4v2PI 1.2.0.Cc update
az agesa is csak egy dolog, azt adja az AMD.
viszont a bios-t a kedves gyarto ugy szabdalja meg, ahogy neki tetszik.
asus-szal csinaltattam magamnak b450-es laphoz egyedi bios-t, mert nem volt benne a PCIE ASPM L0+L1 beallithatosaga. :)
megkerdeztek pontosan milyen cpu-m meg ramom van es kuldtek egyet. ket het volt levelezessel mindennel egyutt.
Szerencsés/kitartó vagy. Volt egy dmraid-ot tudó alaplapom, ahol ez a funkció linux alatt kiválóan működött, de windows alatt a legújabb drverrel sem. Ekor kellett megismerkednem azzal a bios fícsörrel, hogy a windows a bios-ból tölti be a dll-t. Konkrétan ez a dll egy befejezetlen szimfóniának bizonyult és nem lévén bos frissítés, úgy is maradt.
elso korben frissitenek firmware-t ha meg nemvo't.
masodikban pedig feltennek egy aktualis w11-et (fizetni sem kell erte), feltennem a legujabb drivereket es megneznem azzal. ezzel kizarva, hogy szet van barmolva az OS-edben valami, pl. driverek maradvanyai.
ha ugy is sz*r, mehet vissza gariban az eszkoz.
ha jo minosegu usb-s eszkozt keresel, ezt tudom ajanlani:
https://europe.yamaha.com/en/products/proaudio/live_streaming_gaming/ag…
vagy ha tobb savra van szukseged:
https://europe.yamaha.com/en/products/proaudio/live_streaming_gaming/ag…
Koszi, hogy ilyen gagyi szakembernek nézel! :(
Írtam feljebb, hogy az USB nem atomfizika, mert a szabvány közben nem változott. Pl. a MS firewire driver 2006-os, de csak azért, mert 800-as kártyám van. Ha csak 400-as lenne, akkor a 2001-es driver került volna fel, ami az XP óta teszi a dolgát. Elég hályogkovács megoldás a win11, mert abban is ugyanez lenne.
Mivel két másik eszköz is kifogástalanul működik, a topicnyitóban meghallgatható felvétel alapján a forgalmazó a szervizbe továbbította a szerkentyűt. Ebből következően kizárható, hogy a gépemen előforduló low level USB driver hiba lenne. Saccra a gyártó high levelnél van valami gebasz (90%) és valódi hw hiba (10%), bár ennek ellentmond az, hogy Intelen műkiödött.
A jamahahát szeressük, de a Scarlett is igen jól hasít. Az ajánlott eszközök túlmutatnak az igényeimen.
Elég hályogkovács megoldás a win11, mert abban is ugyanez lenne. > nem ezt irtam. olvass ertobben! :) " kizarva, hogy szet van barmolva az OS-edben valami, pl. driverek maradvanyai." hidd el, been there, done that. foleg USB eszkozok eseten egy friss install 0-rol csodakra kepes...
Az ajánlott eszközök túlmutatnak az igényeimen. > nem volt specifikalva :) azert ajanlottam yamahahahat, mert megbizhato gyarto, tapasztalatbol kifogastalan supporttal, minosegi a HW es ert a hanghoz :)
abbol, amit belinkeltel, 99%, hogy ez szoftveres szarakodas. leginkabb f*s driver.
A B verzio az szokott lenni, ha valami full generic TI chipes eszkozt veszel, ami mindennel _IS_ elmegy, mint pl ez: https://www.behringer.com/product.html?modelCode=0601-ADN linux, windows, szerintem meg egy android telefon is "tudja", by default. cserebe nem tud sokat (usb1.1, 48kHz, stereo), de azt barmikor, barmivel :)
Ennél kicsit jobb vagyok. Tudod AIX alalatt negszoktam, hogy egy rendszer tizenévig megy, legfelljebb néha frissítjük. Windows esetén sokáig befagyasztott rendszert használtam, de most a Win 10 nem ilyen. Ismerek még néhány módszert az USB pucolására, mint a friss install. ;) Már ebben a topicban is hencegtem, hogy USB műiszereket (apró motordiagnosztikai eszközöket) fejlesztek. Gyártáskor a programozó adapteren az mcu USB-n is össze van kötve a géppel, mert ellenőrzöm a SN-t és a működést. Ilyenkor 200 eszköz keletkezik a Windowsban. Egy kis freeware programot használok, ami a bejegyzés mindkét felét minta alapján eltávolítja. Egyéb célra ajánlom a Nirsoft usbdevview programját, csak azt érdemes tudni, hogy mi van csatlakoztatva a géphez. Szóval ezekhez a tevékenységekhez nekem nem kell a friss install 0-ról, sem a win11 - a hátam közepére sem. Az USB eszközök - az USB subsysterm újraépítésére létezik más módszer is, mit amikor a "szakember" "legyalulja" a gépet. Ha felraktál egy rendszert, akkor tanuld meg kezelni és karbantartani! Elismerem, hogy ez Windows esetén a művészettel határos, de kitartás!
Igaz, semmi sem volt specifikálva, mert a topic nem arról szól, hogy hangeszközt keresnék, csak összefutottam egy működésképtelennel.
hat, ezt mondd azoknak, akiken a DDU sem segit, csak a reinstall. :) ez a windows mar csak ilyen.
aztan vagy megtalalod a driverek maradekait a rendszeren ezzel-azzal a registryben meg a filerendszeren, vagy nem :) utana meg ha veletlen olyan is ment a levesbe, amit nem kellett volna torolni, az tud "mokas" lenni, lehet setalni a backupert :D
a video hosszabb, mint egy w11 install egy SSD-re, hogy kiprobald megy-e egy eszkoz, az-e a hiba, amirol en beszelek...
ugyebar az usb kommunikal az usb chippel, az kommunikal a pch-val, vagy kozvetlen a pcie-vel, az kommunikal a cpu-val. es ennek mindnek vannak driverei, firwmare-e, bios beallitasai... es akkor az ezeket hasznalo szoftverkornyezet szoba sem jott :)
nekem a legutso ilyen jellegu sci-fi az volt, h az alaplapi 2.5g intel halokartya egyszercsak megszunt mukodni. mindent _is_ kiprobaltam, legyalultam a driveret 0-ra, ujraraktam, megjobban legyalultam, probaltam masik verzios driverrel... nem. nem tudta a windows resetelni a pcie eszkozt. a fix pedig az, hogy poweroff, aram elvesz, bekpcs gomb megnyom, hogy az utolso standby power maradeka is eltunjek, majd bekapcs... :D szerencse, hogy ez egy desktop, nem egy kivehetetlen akksis laptop... ott egy leptekkel nagyobb sz*pas a power elvetele :)
Igen, vannak ilyen tapasztalati úton megszerzett információk, de sajnos ezek nem általánosak. A "clean install" elcsesződésének gyakran nagyobb az esélye, mintha gondosan utánanéznél valaminek. Az tény, hogy egy ilyen univerzális rendszeren, mint a Windows rengeteg fegyelmezetlen fejlesztő dolgozik. Aztán felrakod és úgymarad. :( Kedvencem a minden alaplapon előforduló Realtek hangcsip, amihez a gyártó már nem készít saját szoftvert. Tudod, az a mikor bedugsz valamit és felpattan egy ablak megkérdezvén, hogy ez most milkrofon, fejhallgató vagy line? Helyette van bizony a Nahimic APP, hurrá! Mivel az én Win verzióm nem igazán támogatja az appokat és ezt sem sikerült egyszer sem elindítanom, ezért nem marad más, mint az internet túrása. Némi türelemmel megtalálható a megoldás: Policy editorral kell csinálni két szabályt, hogy ezt NE RAKJA FEL még a Windows Update se! Ehhez kell a szoftvernek a kódja, mert azt is meg kell adni. Majd jön egy órás registry takarítás, hogy írmagja se maradjaon a hülyeségnek, persze file szinten is el kell végezni. Igy, most sikerült eljutni a nálam default konstellációhoz: alaplapi hang lekapcsolva. Maradjunk annyiban, hogy a saját gépemet - amit gondosan lépesenként építgettem fel - én ismerem jobban, és egy gyors google keresés nem szolgáltat elegendő információt a továbblépeshez.
A gondok mögött néha fellelhető az információ morzsája is. Egy linux szerveren hálózatinak tűnő gondjaink voltak. (Végül kiderült: nem iis az volt a baj.) A mindent is tudó üzemeltetö szerint: Mert a Realtek kártya szar és Intel kell bele! A háttérinformáció a következő: A Realtek pcie hálókárty driverét annak idején alaplapi pci (!) driver átpofozásával készítették, de nem sikerült valami jól. A profi üszemeltetők által használt Debian disztróban mindig rágebbi csomagok vannak, mint kellene. De az előbbi információt megszerezve az is oda volt írva, hogy a Debianhoz melyi csomagot kell letölteni. Vagyis nem a Realtek szar az Intel jó, csak valamilyen információnak még nem vagy a birtokában.
Nagy meglepetés ért, amikor Windowsra akartam felrakni az alaplaphoz tartozó RAID szoftvert. Ami ott nem működött, de a linux gond nélkül kezelte. Sajnos a nagyértékű gyártó egy befejezetlen windows dll-t dugott a BIOS-ba, a nyomorult szoftver meg azt próbálta használni. Annak aztán jöhetett clean install és frissítés is - folyamatosan szar maradt.
Dehogy lenne ugyanaz! Hiába nem változott a szabvány, a Linux USB driver-e is fejlődött. Mindent meg lehet írni hibatűrőbbre, robusztusabbra.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Árnyálnaám ezt, saját low level implementációim is fejlődnek olykor, mert vagy rájövök, hogy ügyesen bugot fejlesztettem bele, vagy bővülnek az igények, vagy csak optimalizálok a kódon, esetleg áttekinthetőbbé teszem. Miért ne lehetne hasonlóan az MS-nél, vagy valamelyik hardware gyártónál?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
vagy csak szinmplan kicseszik veled az OS schedulere, nem kap az adott processz eleg idot/io-t megfelelo rendszeresseggel. :) egy olyan bonyolultsagu rendszeren, mint egy desktop... barmi is lehet.
ezert is ajanlottam olyan eszkozt fentebb, amin pl. HW DSP van. :)
Ha csak arra gondolok, h. a Bluetooth SIG hivatalos doksijai mekkora terjedelműek, és hány további reviziót élt meg minden egyes main milestone után, szerintem még a mikroszoft se fejlesztette bele a windows 11 (24H2)-be sem teljes egészében minden részét. Nemhogy bárki hobbi kóder / openszósz kommuniti.
Na, hát ez az! Szóval ezért nem tudok azzal azonosulni, hogy az USB nem atomfizika, meg nem változott a szabvány, tehát egy 2001-ben készült driver ugyanolyan jó, mint a mai, mert ez nincs így.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ennek ellentmondani látszik, hogy amit még XP-hez írtam, az működik Win 11-ig mindennel. Az Audio Class is elég régikeletű, még az XP is beépítetten támogatja az egyszerű topológiával rendelkező USB audió eszközöket. Az én implementációmban csak egy dolgot kellett igazítani. Az alapértelmezett 0,1,2,3 funkció mellett megjelent a MS találmány e1 is, amivel logót, szoftvert, stb. tölthetsz le az USB eszközről. A nálam profibbak bizonyára előbb megírták, hogy a nem értelmezett kódokat figyelmen kívül kell hagyni.
Az XP USB alrendszer majdnem változatlan, de egy kb. 10 éve megjelent bővítés miatt - az XP-re már nem volt - az embedded platformról kellett felrakni egy csomagocskát - a MS tanácsait követve.
Az USB-t fogd fel soros portként, annak a driverében sem találsz új dolgokat, legalábbis a buffered UART alkalmazása óta.
Soros port, csak sokkal bonyolultabb. A legjobb, amikor az USB fölött CDC class megy valami RS232 emuláció, kihalasztod alóla a hordozó, USB réteget, a COM port meg nyitva marad, de onnantól nem tudsz vele mit kezdeni. Nagyjából reboot. Linuxon meg jól kezeli ezt az udev.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nem néz senki gagyi szakembernek. Segíteni próbálnak, mert segítséget kértél, te meg előre eldöntötted, hogy mi a válasz. Egy tartalék drive-ra feldobott Win11 meg egy Live Linux kipróbálása érdekes lenne, hogy ott is ezeket tapasztalod-e. Így lehet szűkíteni a hibaforrást.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Erre ott a szerviz, és mint mondtam a Win11 sem opció, ha egyszer nem azon kellene mennie. Ugyanúgy a linux se, mert az nem is támogatott, ezért még a FreeBSD sem opció. Sokkal jobban jártam, mert kicseréltem egy működőre - ami bizonyos szemszögből ugyanolyan ill. jobb is.
A "driver" kiolvassa az Audio Class elemeit, majd a gyártó által biztosított kis rajzban megjeleníti a keverőt + összekötési lehetőségeket. Ehhez néhány alapművelet kell csak: descriptor és string olvasás. Ezt tényleg eldöntöttem, mert az USB csak egy soros port, ahol a bájtok a nagyobb sebesség miatt keretbe vannak rendezve.
A gagyi szakember -> berakom a kérdést a fórumra, hogy próbáljanak segíteni és közben röhogök, mert nincs fenn a legfrissebb driver?
Mi a topikod célja? Kérdezel, vagy mesélsz? Ha az utóbbi, miért nem blog? A tanácsokat nem fogadod meg, szerintem nincs is rájuk szükséged.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Scarlett: "requires 900mA USB port" - ez szigorúan kell? Nem volt ezzel probléma?
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Itt olvashatod a probléma feloldlását az utolsó bekezdésben. Mivel usb müszereket fejlesztek, ezért ismernem kell a portok kapacitását. Most bedugtam egy műszerkét és csak 0,51A-t fogyaszt a Scarlett. Használok USB oszcilloszkópot, amihez rövid Y kábelt adnak, hogy 2x0,5A-t kaphasson. Azt is mindig egy sima kábellel használom és soha nem sikított még, hogy kevés lenne a villany. Csak vigyázni kell, mert az occó kínaji kábelekben vékony a vezeték, ami 0,5A felett tetemes fezültségesést okozhat. Ezért csak ismert gyártótól veszek kábelt, de olyat, ahol specifikált a tápvezetékek keresztmetszete. Most a Scarlett egy Temus Rövid USB C - USB -A gyorstöltő kábelről megy, ami 53,5 cm hosszú és USB3-ba van dugva, ami hivatalosan is tuja a 900mA-t..
Mi lenne, ha panaszkodás és mindent jobban tudás helyett megfogadnád a tanácsokat és elvégeznéd a nyavajás diagnosztikai lépéséket, amiket írtak!
Fogj egy aktuális ubuntu pendrivet és live módban indítasd el, próbáld ki. Attól, hogy nem ad ügyfélszolgálatot linuxhoz, még a chipset lehet működik alatta.
De egy másik háttértárat betéve, arra win11-et feltéve is kipróbálhatod, hogy működik -e.
Semmilyen plusz információt nem ad az, hogy te milyen usb kütyüket fejlsztel vagy miben hiszel a retro windows verzióknál. Csak vesztegetd mindenki idejét, aki segíteni próbál, mert semmit sem fogadsz meg, nem csinálsz diagnosztikai lépéseket, csak sztorizgatol.
Bizony, azért egy-két dolgot jobban tudok:
Igaz, attól sdenkinek nem lesz jobb, ha én olvastam el néhány ezer oldalt az usb szabványból, vagy ha a konstrukcióm néhány ezer űgyfélnél működik bármilyen csippel XP-től Win 11-ig, bármilyen cpu-val.
Nem nevezném diagnosztikai lépésnek az oprendszer cserét - mert ez is támogatott, sem a gép cseréjét - mert ezen kellett volna mennie. Viszont korábban leírtam, hogy három féle portot is kipróbáltm - igaz hubon keresztül nem, mert ezek a kütyük nem szeretik, kizártam az egér vevőjét és a cpu túlterhelését. Sőt, közben egy Intel core i5-ös kolléga lefuttatta a latency monitort - az én gépem lényegesen fürgébb.
Ugye közben ki is cseréltem az eszközt egy olyanra, ami működik is. Ennek a szépséghibája mindössze annyi, hogy ök le is írják, hogy a driverük Intel/AMD platformon megy, míg az M-Audio semmi ilyesmit nem ír. Az én hibám: oda kellett volna figyelni. :-D
Tudom, Intel csip lenne az igazi, csak ennek ellentmond, hogy nálam minden más működik ezen az egy eszközön kívül.
Hogy jobban értsed a topic célját: Lehetséges-e úgy megírni egy drivert (ebben az esetben inkább szoftvert - ezt is kifejtettem feljebb) , hogy a fenti konfiguráción fejre álljon. És mi a lényegi eltérés ebben a konfigurációban, ami miatt ezt teszi. (Az Intel csip hiánya nem a jó válasz!)
"Hogy jobban értsed a topic célját: Lehetséges-e úgy megírni egy drivert (ebben az esetben inkább szoftvert - ezt is kifejtettem feljebb) , hogy a fenti konfiguráción fejre álljon. És mi a lényegi eltérés ebben a konfigurációban, ami miatt ezt teszi. (Az Intel csip hiánya nem a jó válasz!)"
Lehetséges. Pl ha mondjuk olyan utasitáskészletkiterjesztést használsz, amit az egyik cpu támogat, a másik meg nem.
Pl a nyitóban említett 4300G még nem supportálja az AVX512 -t. ( amit aztán a 13-14 gen Intelből a kismagok miatt kivettek, de ez most lényegtelen. ) Szóval lehet a bepróbált Intel proci valami avx512 kódutat használ ; míg az AMD -n --ha van -- kénytelen AVX256 -os kódutat használni. ugyanakkor a Zen2 ( mert ugye a 4300G az ) ezt 2 darab 128 bites utasitásra felosztva hajtja végre, ami Intelen lefutna 1 ciklus alatt ; a 4300G -n 2 ciklus. ( Ha avx512 -ben szamolunk, akkor 4 ciklus ) Ha Zen3 lenne, abban már teljes szélességű AVX256 support van, és ugyanúgy 1 ciklus, mint az Intel procin ; igaz Avx512 még ottsincs, csak a Zen4 -ben, de ott megint 2x256 bitre van bontva...
HUP te Zsiga !
cpu-k kozott sok a kulonbseg, pl. az intel 2 betuvel tobb :)
komolyra forditva nyilvan nem a cpu itt a lenyeg hanem az ahhoz kapcoslodo / attol fuggo chipset, io busz. pl. az usb vezerlo tok mas, egyik uhci maisk ohci, bar ez csak usb 1.x-nel volt asszem, de latszik hogy meg ebben sem sikerult egyeterteniuk... nyilvan millio mas elteres is lehet az alaplapok kozott, ezret is lehet hogy van akinek amd cpuval is mukodik, de biztos mas az alaplapja.
Éppen ezért érdekes az AMD+AMD chipset független - igaz csak kínai - USB3 csatolóval is hasonlóan rosszul működik. Pedig az menne egy Intel alkatrészekből összeállított géppel is. Kíváncsan várom a szerviz visszajelzését, hogy a kütyü döglött-e meg, vagy tényleg AMD inkompatibilis.
Amit végképp nem értek, a jelenség olyan, mintha X alaplappal nem működne a HTML. :-D Mert az audio class kb. ott van az usb protokollhoz képest, mint az ethernet driver a htmlhez. Igaz, volt egy olyan esetem, hogy a vi editorban nem működött a cursor down, de a szakember hálókártya cserével megjavította! :-D
A hibáikban nem feltétlenül kompatibilisek.
:)
Egyebkent de, lehet elteres AMD es Intel kozott.
A kernel szintjen ugyanis a 2 processzor nagyon maskepp mukodik. Ezert a kernel schedulere is mas: gondolj csak az intel heterogen core-jaira, de a hyperthreading is ide tartozik. Aztan ugye a power management, mikor mit melyik core-ra schedule-oljon a kernel, hogy elossza a hotermelest, de ugyanide tartozik meg az is, hogy mikor melyik mag mekkora frekin uzemel vagy milyen deep sleep state-ben van.
Egy szo, mint szaz, *specifikusan* a real-time scheduling kornyeken bizony komoly elteresek lehetnek. Itt mondjuk mar bejatszik meg az alaplap meg az usb kontroller chip is -- mennyire komolyak az idozitesei, hogyan kezeli a deep sleep-et/milyen gyorsan kepes 'felebredni', pl.
Alapvetoen a gyartonak tesztelnie kellene tobbfele rendszeren is; nezd meg a requirements-eket! Ha azt irja, 'Intel processor', akkor egy szot se szolhatsz, megmondta, hogy Intel procin tesztel csak. Ha azt irja, 'Intel-compatible processor', akkor kuldd vissza a termeket, mert hibas. Ezek az aprosagok sajnos nagyon fontosak fogyasztoi jogban.
Szerintem ez a különbség sereg nem okozhana gondot, mert kernel api szinten legfeljebb ilyennel kellene találkozni pl. register_interrupt_handler()/register_event(), stb.
Az ACPI api is hasonló lehet.
A requirements: PC: Windows 7, Windows Driver/Standard USB 2.0 or USB-C Port, míg a másiknál leírják, hogy Intel/AMD CPU kell.
Simple birkaként akár mindkettő jelentheti ugyanazt, de a Windowsw 7-ből nem kéne következnie a !=AMD feltételezésnek. Az értelemszeűen >= Windows 7 pedig nem jelentheti a Win 11 jó de Win 10 rossz esetet.