Čo ste dnes urobili, kúpili alebo čím ste si spravili radosť... (Stránka 211 z 422)

Co vy na to ?
Nevšední barva...

Benazi: Copak je to za pěkná tráfka ? Na co se chystáš ?

kde sa k tomu da dostat ?

@right13: To je limitovaná serie stavebnice (některé věci bylo nutné dokoupit) od Luty. Já jsem se k tomu dostal tak, že se jeden vlastník rozhodl, že ji prodá. Původně jsem totiž neuvažoval, že budu ten DAC stavět, ale když jsem stavebnici viděl v bazaru hifi.slovanet.sk tak jsem neodolal a rozhodl jsem se, že DAC vyzkouším. Další motivací bylo, že stále zápasím s feedbackem u svého transportu a tady uvidím USBlyzer-em jak to v reálu vypadá.

@Dohnalik: Jsi machr. Vzhledem k tomu, že mám jistou představu s čím se budeš potýkat tak jestli to dáš a bude to fungovat jak má tak máš o zákazníky postaráno.
O.T.: Jinak díval jsem se na ten tvůj dotaz/odpověď ohledně toho OUT Endpointu u Audio-Widgetu a i kdyby tam bylo omezení na 512 bytů tak můžeš pořád posílat 96/16 tj. 2 bytes * 2 ch * (96 + 1) samples = 388 bytes. Ale vzhledem k tomu, že použili 24 bitů pro 44,1 a 48 tak se asi nechtěli zbytečně pouštět do podpory pro 16 bitů. Ten descriptor je pak složitější a je docela možné, že narazili na podobnou věc s kterou se teď potýkám já a to, že se IN endpoint chová jak chytrá horákyně. Jinak to omezení je celkem zajímavá informace, kterou budu muset ověřit i u toho svého hebla. Já jsem sice schopen jet na 96, ale pouze pro 16 bitů. Ale upřímně příjde mi to divné, protože jsem se o tom omezení nikde nedočetl a i Benchmark DAC1 USB umí 24/96 a když to počítám tak i bez feedbacku těžce přes 512 (576).

S těma 16 bit vypadá, že je to tam problémovější. Deskriptory který to definuje má danou nejvyšší bitovou hloubku, kterou je schopný ten transport zvládnout, to jistě víš. Když se tam definuje 44.1 a 48 v 24 bitech, tak 96 už logicky jen v 16 bitech nelze (pokud se nemýlím). Ale to mě moc netrápí

Ovladače jsou momentálně ve stádiu takovém, že se úspěšně načtou do systému a naparsujou deskriptory, za chvilku to bude o tom otevřít endpointy a zkusit do nich poslat sinus tabulku, aby to začlo pískat s tím, že je potřeba vyřešit ten feedback, který by snad neměl být tak složitý (stačí jen upravovat množství dat v dalších rámcích podle toho co si vyžádá feedback endpoint). Pokud to bude potud fungovat, tak se na to napojí kernel streaming (KS + DS, viz http://msdn.microsoft.com/en-us/library … s.85).aspx ) Jak říkám, kvůli co nejnižší latenci to běží přímo v jádru systému a je to psané velmi univerzálně, tak jak specifikace diktuje, tj. mělo by to fungovat se všemi transporty vyhovující UAC2 (XMOS, AVR32, můj ARM based atd...) a v budoucnu se do toho zakomponuje taktéž mixér, možná resampler (nevím jak moudré je něco takového cpát do kernelu) a spousta feature. Bude to umět (pokud vše půjde dobře) nativní DSD přes ASIO a to včetně nahrávání.

MS na to má i příklady, nikdo to nepíše od píky, to snad ani nejde . To co jsi napsal vím, ale nevěděl jsem, že se to pak dá interně přepínat, do toho se vážně pouštět nehodlám Ono ani těch 96 KHz jenom při 16 bitech nemá smysl. Já si pak akorát definuju vedlejší HID interface pomocí kterého budu do hosta posílat věci jako "next track" a ještě komunikovat s ovládacím panelem ovladačů (tj například procesor pošle info že detekoval DSD a přepl mod). A taky si nemysli, že ty ovladače píšu já a ještě sám, já se do takových věcí nepouštím Děláme na tom společně. Kdybys chtěl nějaký větší info tak už se asi přesuneme do SZ/na email, myslím, že většina lidí nemá moc tušení a o čem to melem a ani je to nezajímá A rád bych se tě ještě na něco zeptal.