Portál AbcLinuxu, 25. dubna 2024 13:51
VU meter (peak meter) se občas docela hodí, spoustu win ovladačů jej má. Pro čipy Envy24 existuje Xkový envy24control, ovšem ten funguje jen pro starší modely ice1712. U ice1724 si postěžuje a skončí.
Správným řešením by samozřejmě bylo do jeho zdrojáků přidat podporu ice1724. Než k tomu dojde (hlásí se někdo? :) ), můžete zkusit triviální příkaz:
while true; do amixer cget name="Multi Track Peak" | grep ": values"; sleep 0.5; doneJak to funguje? Ovladač ice1712 i ice1724 umí číst příslušné registry čipu Envy24. Jde o registry MT3E a MT3F (viz str. 56 datasheetu ). Ovladač hodnoty načítá do 22-místého read-only ovládacího prvku Multi Track Peak, kde každá položka odpovídá dle datashetu:
00000: Playback stream 1 (PDMAi slot 1) 00001: Playback stream 2 (PDMAi slot 2) 00010: Playback stream 3 (PDMAi slot 3) 00011: Playback stream 4 (PDMAi slot 4) 00100: Playback stream 5 (PDMAi slot 5) 00101: Playback stream 6 (PDMAi slot 6) 00110: Playback stream 7 (PDMAi slot 7) 00111: Playback stream 8 (PDMAi slot 8) 01000: S/PDIF Left stream (PDMA4 slot 1) 01001: S/PDIF Right stream (PDMA4 slot 2) 01010: Record0 Left stream (RDMA0 slot 1) 01011: Record0 Right stream (RDMA0 slot 2) 01100: ignored. 01101: ignored. 01110: ignored. 01111: ignored. 10000: ignored. 10001: ignored. 10010: Record1 Left stream (RDMA1 slot 1, typ. S/PDIF Right input stream) 10011: Record1 Right stream (RDMA1 slot 2, typ. S/PDIF Right input stream) 10100: ignored. 10101: ignored.
Jednotlivé položky odpovídají 8 horním bitům maximální hodnoty, vyskytující se v daném kanálu od posledního čtení registru.
Některé hodnoty Multi Track Peak se vypisují např. i v alsamixeru, ale protože ten nevolá opakovaně čtecí metodu tohoto prvku (a navíc díky chybě ve svém kódu dovoluje v tomto prvku nesmyslně ručně měnit hodnotu), často uživatelé netuší, k čemu slouží. Jenom při spuštění se načtou aktuální hodnoty špiček z čipu, což také na významu nepřidá.
Výše uvedený příkaz jenom opakovaně čte Multi Track Peak z čipu přes amixer a vypisuje datový řádek s hodnotami. Příklad - různé signály jdou do front a SPDIF výstupů:
: values=203,180,0,0,0,0,0,0,174,185,0,0,0,0,0,0,0,0,0,0,0,0 : values=149,198,0,0,0,0,0,0,184,226,0,0,0,0,0,0,0,0,0,0,0,0 : values=164,171,0,0,0,0,0,0,183,196,0,0,0,0,0,0,0,0,0,0,0,0 : values=173,185,0,0,0,0,0,0,154,152,0,0,0,0,0,0,0,0,0,0,0,0 : values=174,226,0,0,0,0,0,0,189,200,0,0,0,0,0,0,0,0,0,0,0,0Samozřejmě by šlo zařídit hezčí výpis, ale pro sledování stavu kanálů mi to stačí.
Tiskni
Sdílej:
ASIO2. WDM/MME/DirectSound. x64 Drivers WDM: 2-in/8-out at 44.1kHz, 48kHz, 88.2kHz, 96kHz WDM: 2-in/4-out at 176.4kHz & 192kHzOmezení u WDM bude asi spíše záležitost ovladače než HW. Ty vstupy, o kterých píšeš, se mixují interně v tom DSP a přes PCI do ovladače zřejmě nejdou - to by měly řešit právě ty ASIO vstupy/výstupy. Koukal jsem do emupcm.c a viděl bych to možná takto: Ten ovladač pracuje se standardním vstupem do audigy přes kodek AC97 - snd_emu10k1_capture_open pro snd_emu10k1_pcm. Pak je tam ještě mikrofonní vstup - snd_emu10k1_capture_mic_open pro snd_emu10k1_pcm_mic. Ten má (zdá se) natvrdo nastavené vzorkování 8kHz. A pak jsou tam ty efx vstupy/výstupy audigy pro externí DSP. K tomu je zřejmě připojeno v emu1010 to FPGA a pracuje se tam s těmi násobky 16bitových "kanálů" pojmenovaných v emu101.h jako EMU32. Proto jsou z tohoto důvodu asi klíčová efx PCM. Jsou tam playback i capture a u obou se nastavuje počet kanálů (u playbacku natvrdo pro 44.1/48kHz, u capture už je zakomentovaná podpora pro jiné frekvence, ale určitě to není dodělané). Nicméně tvá původní otázka směřovala na ADAT vstupy. Řekl bych, že v emu10k1.h už jsou vytažené potřebné hodnoty registrů přepínačů vstupů v FPGA (HANA):
#define EMU_SRC_HANA_ADAT 0x0400 /* Hana ADAT 8 channel in +0 to +7 */
V emumixer.c bych taky řekl, že to přepínání umožňuje, protože příslušné konstanty se tam používají v emu1010_src_regs, které se využívají pro v snd_emu1010_input_source_put atd.
Dokonce bych řekl, že se tam hezky vybírá, který fyzický vstup (registr) (emu1010_src_regs) bude přepnut na který vstup do audigy (emu1010_input_dst) - viz spoustu nechutně velkých enumů snd_emu1010_output_enum_ctls/snd_emu1010_input_enum_ctls.
V emu10k1_main.c:snd_emu10k1_emu1010_init je pěkně vidět, jak se mapují efx výstupy/vstupy audigy (Alice2) na vstupní/výstupní registry Hany. V podstatě stejný způsob by mělo jít využít při ručním nastavení propojení (v alsamixeru) např. ADAT4 třeba na EMU_DST_ALICE2_EMU32_0 (na který by měl být dle defaultu v snd_emu10k1_emu1010_init nastaven vstup EMU_SRC_DOCK_MIC_A1). Asi by to mělo chodit, je tam vlastně jenom pár principů, které se točí dokola.
Ještě si trochu pohrát s konverzí 16bitových kanálů alice2 na alsácké pcm - tam bude spoustu práce pro vyšší frekvence, muselo by se řešit mapování více kanálů na jedno pcm, to bych řekl, že zatím v kódu kolem snd_emu10k1_fx8010_playback_ops/snd_emu10k1_capture_efx_ops není.
Uff, jdu spát.
if (hw_info.type == SND_CARD_TYPE_ICE1712)
break;
zkusil bych rozsirit podminku o ICE1724 karty. Ted ale nevim, zda takovy typ existuje a odkud se bere ?
Otestoval bych to u sebe, ale ted nemam silu resit, ze se nerozjede ani configure skript [debian statically linked library....].
Mozna to nekde sleti. Ctou se udaje z eeprom a nevim, jak je ICE1712 a ICE1724 mezi sebou navzajem kompatibilni.
Mozna, ze by port na ICE1724 mohl byt velmi jednoduchy. Ale nevim.
Nekde se toto resilo, ale kde to uz nevim. Tolik moje hlava jiz nebere.
Posli kdyztak nejakou hlasku na cem to sleti. Klidne soukrome nebo do diskuse. I kdyz o tomto si tady popovidame asi jen par lidi. Mozna Ctirad Fert by mohl vedet podstatne vice nez ja.
Vice nejak pozdeji.
Pavel Kysilka
emu->card_capabilities->xxxxx. Mělo by to být i vidět v aplay -l v názvu PCM streamu.
Obávám se, že datasheety nepošle, protože kvůli nim podepsal NDA: http://music.columbia.edu/pipermail/linux-audio-dev/2006-November/017068.html:(
Ale info by dát mohl :)Uvidíme. Když jsem reagoval na nějaký jeho maily ohledně emu v LAD, tak vůbec neodpověděl :(
Co jsem (málo) pochopil, tak emu1212 má ca0102 jenom jako takový PCI/DMA řadič a veškerá logika i časování je v tom FPGA.Přesně tak.
ca0102 běží ve slave režimu a jenom poskytuje těch 32 8bitových 44.1/48kHz EMU32 kanálů do FPGA. Vždy jede ve 24 bitech (interně asi ve 32b, předává SNDRV_PCM_FMTBIT_S32_LE), tedy shlukuje je vždy po čtyřech (dle dokumentace v emupcm.c:1248). Tudíž pro 44.1/48kHz potřebuje 4 EMU32 na jeden kanál, tedy umí 8 mono kanálů, pro 96kHz potřebuje 8 osmibitů (tedy umí poskytnout 4 mono kanály), na 192kHz potřebuje 16 osmibitů, tedy umí pouze 2 mono kanály).No to určitě ne. Ta I/O karta 1010 (stejná pro 1212m i 1820m) umí na 100% 8 24 bitových kanálů oběma směry na 192kHz + S/PDIF (teď nevím, jestli ten nekončí už na 96kHz) + ADAT (tj. 8 kanálů na 44.1/48kHz, 4 na 96KHz ve SMUXu a 2 na 192kHz). Ono je to ještě složitější o to, že ADAT se dá přepnout na druhý S/PDIF a ještě jeden S/PDIF out je na docku.
ASIO2. WDM/MME/DirectSound. x64 Drivers WDM: 2-in/8-out at 44.1kHz, 48kHz, 88.2kHz, 96kHz WDM: 2-in/4-out at 176.4kHz & 192kHzOmezení u WDM bude asi spíše záležitost ovladače než HW. Ty vstupy, o kterých píšeš, se mixují interně v tom DSP a přes PCI do ovladače zřejmě nejdou - to by měly řešit právě ty ASIO vstupy/výstupy. Koukal jsem do emupcm.c a viděl bych to možná takto: Ten ovladač pracuje se standardním vstupem do audigy přes kodek AC97 - snd_emu10k1_capture_open pro snd_emu10k1_pcm. Pak je tam ještě mikrofonní vstup - snd_emu10k1_capture_mic_open pro snd_emu10k1_pcm_mic. Ten má (zdá se) natvrdo nastavené vzorkování 8kHz. A pak jsou tam ty efx vstupy/výstupy audigy pro externí DSP. K tomu je zřejmě připojeno v emu1010 to FPGA a pracuje se tam s těmi násobky 16bitových "kanálů" pojmenovaných v emu101.h jako EMU32. Proto jsou z tohoto důvodu asi klíčová efx PCM. Jsou tam playback i capture a u obou se nastavuje počet kanálů (u playbacku natvrdo pro 44.1/48kHz, u capture už je zakomentovaná podpora pro jiné frekvence, ale určitě to není dodělané). Nicméně tvá původní otázka směřovala na ADAT vstupy. Řekl bych, že v emu10k1.h už jsou vytažené potřebné hodnoty registrů přepínačů vstupů v FPGA (HANA):
#define EMU_SRC_HANA_ADAT 0x0400 /* Hana ADAT 8 channel in +0 to +7 */
V emumixer.c bych taky řekl, že to přepínání umožňuje, protože příslušné konstanty se tam používají v emu1010_src_regs, které se využívají pro v snd_emu1010_input_source_put atd.
Dokonce bych řekl, že se tam hezky vybírá, který fyzický vstup (registr) (emu1010_src_regs) bude přepnut na který vstup do audigy (emu1010_input_dst) - viz spoustu nechutně velkých enumů snd_emu1010_output_enum_ctls/snd_emu1010_input_enum_ctls.
V emu10k1_main.c:snd_emu10k1_emu1010_init je pěkně vidět, jak se mapují efx výstupy/vstupy audigy (Alice2) na vstupní/výstupní registry Hany. V podstatě stejný způsob by mělo jít využít při ručním nastavení propojení (v alsamixeru) např. ADAT4 třeba na EMU_DST_ALICE2_EMU32_0 (na který by měl být dle defaultu v snd_emu10k1_emu1010_init nastaven vstup EMU_SRC_DOCK_MIC_A1). Asi by to mělo chodit, je tam vlastně jenom pár principů, které se točí dokola.
Ještě si trochu pohrát s konverzí 16bitových kanálů alice2 na alsácké pcm - tam bude spoustu práce pro vyšší frekvence, muselo by se řešit mapování více kanálů na jedno pcm, to bych řekl, že zatím v kódu kolem snd_emu10k1_fx8010_playback_ops/snd_emu10k1_capture_efx_ops není.
Uff, jdu spát.
ASIO channels are reduced to 8 ASIO (4 stereo) channels at 88k/96k, and 4 ASIO (2 stereo) channels at 176k/192kHz.To mi připadá jako tiskový šotek. Hned v tom následujícím dodatku 6 mají tabulku jak se redukuje počet I/O při použití 176/192kHz a je tam číslo 8 i so obrázky jak se to dá kombinovat. Ostatně kdyby to omezení bylo opravdu takhle brutální, tak by se nedaly použít všechny I/O ani na 1212M, natož na 1820M nebo 1616M, dokonce ani na 44.1kHz! Zeptám se schválně, známého co to ve studiu používá, z kolika vstupů může nahrávat na 96k a výš. Na 44.1kHz nahrává do 16 stop (1820 + ADAT), to vím bezpečně.
Ty vstupy, o kterých píšeš, se mixují interně v tom DSP a přes PCI do ovladače zřejmě nejdou - to by měly řešit právě ty ASIO vstupy/výstupy.ASIO nejsou vstupy, ale alternativní ovladačové API, které navrhnuli velcí hráči na trhu s aoudio softwarem, protože tehdejší vfw bylo naprosto nepoužitelné. wdm je na tom o něco líp.
A pak jsou tam ty efx vstupy/výstupy audigy pro externí DSP. K tomu je zřejmě připojeno v emu1010 to FPGA a pracuje se tam s těmi násobky 16bitových "kanálů" pojmenovaných v emu101.h jako EMU32. Proto jsou z tohoto důvodu asi klíčová efx PCM.Aha, to dává smysl.
Dokonce bych řekl, že se tam hezky vybírá, který fyzický vstup (registr) (emu1010_src_regs) bude přepnut na který vstup do audigy (emu1010_input_dst) - viz spoustu nechutně velkých enumů snd_emu1010_output_enum_ctls/snd_emu1010_input_enum_ctls. V emu10k1_main.c:snd_emu10k1_emu1010_init je pěkně vidět, jak se mapují efx výstupy/vstupy audigy (Alice2) na vstupní/výstupní registry Hany. V podstatě stejný způsob by mělo jít využít při ručním nastavení propojení (v alsamixeru) např. ADAT4 třeba na EMU_DST_ALICE2_EMU32_0 (na který by měl být dle defaultu v snd_emu10k1_emu1010_init nastaven vstup EMU_SRC_DOCK_MIC_A1). Asi by to mělo chodit, je tam vlastně jenom pár principů, které se točí dokola.Tohle by mělo nastavovat jenom interní routování na kartě samotné, obdobně jako to má ice1712 nebo RME.
Ještě si trochu pohrát s konverzí 16bitových kanálů alice2 na alsácké pcm - tam bude spoustu práce pro vyšší frekvence, muselo by se řešit mapování více kanálů na jedno pcm, to bych řekl, že zatím v kódu kolem snd_emu10k1_fx8010_playback_ops/snd_emu10k1_capture_efx_ops není.Vyšší frekvence mě celkem netankují. Alespoň zatím. Vše, co potřebuju, je možnost nahrávat ze všech dostupných vstupů (tj. v mém případě 12) a 4 výstupy (DAC + S/PDIF). Jestli to nerozchodím v dohledné době, tak si budu muset koupit jinou kartu :(
#define EMU_SRC_ALICE_EMU32A 0x0300 /* Alice2 EMU32a 16 outputs. +0 to +0xf */ #define EMU_SRC_ALICE_EMU32B 0x0310 /* Alice2 EMU32b 16 outputs. +0 to +0xf */Vstupy z hany do alice (capture):
#define EMU_DST_ALICE2_EMU32_0 0x000f /* 16 EMU32 channels to Alice2 +0 to +0xf */ ... #define EMU_DST_ALICE2_EMU32_F 0x000f /* 16 EMU32 channels to Alice2 +0 to +0xf */Všechny výše uvedené jsou mezi možnostmi v enumech mixeru. Pro každý fyzický výstup (emu1010_output_dst[] - všechny možné fyzické výstupy) nebo výstup do audigy - tedy v podstatě capture vstupy (emu1010_input_dst[] - mezi nimi jsou i capture vstupy do audigy EMU_DST_ALICE2_EMU32_X) si můžeš určit, co se na to připojí jako zdroj signálu - emu1010_src_regs[]. Tam najdeš všechny možné zdroje signálu v Haně - fyzické vstupy i výstupy z alice, tedy playback kanály. Tedy si můžeš např. vstup ADAT4 přesměrovat třeba na pravý analogový výstup na 0202 (v controlu "0202 DAC Right Playback Enum" vybereš "ADAT 4"). Stejně tak to jde přesměrovat na pcm pro capture. Tady to chce vyzkoušet, ale mělo by fungovat něco jako v controlu "DSP 0 Capture Enum" zvolit zase položku "ADAT 4". Dle komentáře v snd_emu10k1_capture_efx_open zřejmě počítají s 24bitovými vstupy (navíc se nastavuje typ na SNDRV_PCM_FMTBIT_S32_LE), tedy pcm stream "Multichannel Capture/PT Playback" má pouze 8 kanálů. Pak DSP0 bude zřejmě prvních 16 bitů prvního kanálu. Problém je řekl bych v nekonzistenci nastavení snd_emu10k1_capture_efx_open, kde se mluví o 24 bitech (tedy pouze 8 kanálech, nastavuje S32_LE), ale v defaultním nastavení emu10k1_main.c:snd_emu10k1_emu1010_init se jednotlivé kanály EMU32 chovají přímo jako jednotlivé kanály 8kanálového "Multichannel Capture/PT Playback", tedy pouze 16bitové. Taky se tam využívá pouze 8 EMU32. Možná kdybys v snd_emu10k1_capture_efx_open nastavil 16 kanálů a pro ně si vybral požadované zdroje signálu, tak by to taky fungovalo, samozřejmě jenom v 16 bitech.
/* The next two are the Audigy equivalent of FXWC */ /* the Audigy can record any output (16bit, 48kHz, up to 64 channel simultaneously) */ /* Each bit selects a channel for recording */ #define A_FXWC1 0x74 /* Selects 0x7f-0x60 for FX recording */ #define A_FXWC2 0x75 /* Selects 0x9f-0x80 for FX recording */Jestli jsem to dobře pochopil, každý z hlasů umí zřejmě vyvolat přerušení a PCM se z těchto hlasů skládají. Potřeboval bych výpis všech ovládacích prvků (tedy i PCM) - výstup příkazu
amixer contentsJde mi speciálně o control "Captured FX8010 Outputs", ale hodí se všechny. Pak by se MOC hodil výstup emuproc.c - parametry karty v /proc. K tomu bude potřeba zkonfigurovat alsu s CONFIG_SND_DEBUG a prosím použít nejaktuálnější ovladače z alsa-hg - viz můj minulý blog. Bez nich stejně nejde posílat patche do konference. Rád bych, abychom to nevzdali a zkusili to alespoň trochu dotáhnout do konce - posunout podporu té karty pro všechny o kousek dál. Strávil jsem nad tím už pěkných pár hodin a hodně nerad bych ten čas jen tak odepsal.
EMU32 jsou 32bitové kanály, viz úvod do FX8010 www.iua.upf.es/dafx98/papers/HOG63.PSNa tenhle dokument jsem narazil, když jsem hledal rozumy na stránkách kxprojectu. Původně jsem to pochopil tak, že je to 32 bit architektura s 32 kanály (16bit) oběma směry, ale opravdu tam tvrdí něco o 32 bitovém I/O. To ovšem stále neřeší otázku, proč je jich ve směru A->H 2x tolik. Asi si vezmu z práce komp s okýnkama, strčím jí tam a projdu si možnosti routování a udělám z toho tabulku.
Na slepo jsem zkusil zvýšit počet kanálů efx capture substreamu z osmi na 16. Patch zde, zkus, co to udělá. Pravděpodobně to chodit nebude, to by byla obrovská náhoda. Určitě to tam ještě někde bude natvrdo a nebo je to úplný nesmysl :)Večer zkusím. V mezičase jsem zkoušel rozchodit synchronizaci na externí clock od S/PDIF a ADAT. Bohužel to nefunguje :( Když toho registru zapíšu hodnotu, která by měla přepnout kartu na externí synchronizaci, tak se sice něco stane (na S/PDIF out mám krabici, co mi ukazuje hodiny), ale hned se to přepne zase zpátky na default 48k. Někdy se to dokonce přepne na 44.1k, ale patrně to jenom nějak "plave", protože když na druhé krabici připojené na S/PDIF out přepínám hodiny výstupu, tak se nic neděje. Zvuk tam taky žádný neleze. ADAT je ještě divnější. Když se na něj přepnu, tak hodiny na výstupu úplně zmizí (což je OK, protože já na ten vstup nic připojeného nemám, prootže převodník jsem si ještě nekoupil ani nepůjčil), ale pak už to nejde přepnout nikam, karta úplně odumře a nepomáhá ani reload modulů nebo reboot systému. Je potřeba úplně odpojit napájení. Obávám se, že bez dokumentace nebo alespoň nápovědy od někoho z dokumentací s tou inicializací nehnu (leda jestli neexistuje nějaká možnost, jak to odchytit z win ovladače) a James nereaguje :(
#define EMU_HANA_WC_SPDIF_HI 0x28 /* 0xxxxxx 6 bit SPDIF IN Word clock, upper 6 bits */ #define EMU_HANA_WC_SPDIF_LO 0x29 /* 0xxxxxx 6 bit SPDIF IN Word clock, lower 6 bits */ #define EMU_HANA_WC_ADAT_HI 0x2a /* 0xxxxxx 6 bit ADAT IN Word clock, upper 6 bits */ #define EMU_HANA_WC_ADAT_LO 0x2b /* 0xxxxxx 6 bit ADAT IN Word clock, lower 6 bits */ #define EMU_HANA_WC_BNC_LO 0x2c /* 0xxxxxx 6 bit BNC IN Word clock, lower 6 bits */ #define EMU_HANA_WC_BNC_HI 0x2d /* 0xxxxxx 6 bit BNC IN Word clock, upper 6 bits */ #define EMU_HANA2_WC_SPDIF_HI 0x2e /* 0xxxxxx 6 bit HANA2 SPDIF IN Word clock, upper 6 bits */ #define EMU_HANA2_WC_SPDIF_LO 0x2f /* 0xxxxxx 6 bit HANA2 SPDIF IN Word clock, lower 6 bits */Nevím, co se myslím upper 6 bits, lower 6 bits. Původně jsem myslel, že bude potřeba vybrat, který z mnoha vstupů daného typu (SPDIF, ADAT, BNC) hodiny poskytuje, ale o výběru vstupu pro hodiny se nikde ve win manuálu nemluví, navíc jsem se dočetl, že ADAT je synchronní a nevybírá se, který kanál poskytuje zdroj hodin. Význam těchto registrů fakt netuším, nikde se nepoužívají a na netu nejsou. Ohledně sekání - možná nebyl nastavený default clock na některou z interních frekvencí a když nic nenadetekoval zvenku, tak se švihl.
Myslím si, že v emu1010 vede do hany 32 32bitových kanálů (EMU_SRC_ALICE_EMU32A/B) a zpět 16 32bitových kanálů (EMU_DST_ALICE2_EMU32_0-F).Jo, tak to vidím taky. Zaujaly mě tyhle definice týkající se audigy čipu:
#define A_FXBUS(x) (0x00 + (x)) /* x = 0x00 - 0x3f FX buses */ #define A_EXTIN(x) (0x40 + (x)) /* x = 0x00 - 0x0f physical ins */ #define A_P16VIN(x) (0x50 + (x)) /* x = 0x00 - 0x0f p16v ins (A2 only) "EMU32 inputs" */ #define A_EXTOUT(x) (0x60 + (x)) /* x = 0x00 - 0x1f physical outs -> A_FXWC1 0x79-7f unknown */ #define A_FXBUS2(x) (0x80 + (x)) /* x = 0x00 - 0x1f extra outs used for EFX capture -> A_FXWC2 */ #define A_EMU32OUTH(x) (0xa0 + (x)) /* x = 0x00 - 0x0f "EMU32_OUT_10 - _1F" - ??? */ #define A_EMU32OUTL(x) (0xb0 + (x)) /* x = 0x00 - 0x0f "EMU32_OUT_1 - _F" - ??? */ #define A_GPR(x) (A_FXGPREGBASE + (x))Data z Hany jdou na ty A_P16VIN, zatímco dalších 16 A_EXTIN zdá se leží ladem. To mi přijde zvláštní.
Ohledně přepínání wordclocku - dal jsi to jako další option do MIXER controlu snd_emu1010_internal_clock? Tvůj popis by napovídal, že je to jenom v inicializaci a ten control si to zase přepne zpět po otevření alsamixeru.Přidal jsem to právě do toho snd_emu1010_internal_clock jako položky SPDIF a ADAT. Hrál jsem si s nastavením tohodle registru:
#define EMU_HANA_WCLOCK 0x05 /* 0000xxx 3 bits Word Clock source select */
/* Must be written after power on to reset DLL */
/* One is unable to detect the Audio dock without this */
#define EMU_HANA_WCLOCK_SRC_MASK 0x07
#define EMU_HANA_WCLOCK_INT_48K 0x00
#define EMU_HANA_WCLOCK_INT_44_1K 0x01
#define EMU_HANA_WCLOCK_HANA_SPDIF_IN 0x02
#define EMU_HANA_WCLOCK_HANA_ADAT_IN 0x03
#define EMU_HANA_WCLOCK_SYNC_BNCN 0x04
#define EMU_HANA_WCLOCK_2ND_HANA 0x05
#define EMU_HANA_WCLOCK_SRC_RESERVED 0x06
#define EMU_HANA_WCLOCK_OFF 0x07 /* For testing, forces fallback to DEFCLOCK */
#define EMU_HANA_WCLOCK_MULT_MASK 0x18
#define EMU_HANA_WCLOCK_1X 0x00
#define EMU_HANA_WCLOCK_2X 0x08
#define EMU_HANA_WCLOCK_4X 0x10
#define EMU_HANA_WCLOCK_MULT_RESERVED 0x18
a pak to ještě kombinovat s tímhle:
#define EMU_HANA_IRQ_ENABLE 0x09 /* 000xxxx 4 bits IRQ Enable */ #define EMU_HANA_IRQ_WCLK_CHANGED 0x01 #define EMU_HANA_IRQ_ADAT 0x02 #define EMU_HANA_IRQ_DOCK 0x04 #define EMU_HANA_IRQ_DOCK_LOST 0x08I v různém pořadí.
Bohužel netuším, k čemu slouží registry:Já taky ne. Hádám se to týká nějakého timecode a k samotné synchronizaci to není potřeba.
Původně jsem myslel, že bude potřeba vybrat, který z mnoha vstupů daného typu (SPDIF, ADAT, BNC) hodiny poskytuje,Tak by to mělo fungovat.
ale o výběru vstupu pro hodiny se nikde ve win manuálu nemluví, navíc jsem se dočetl, že ADAT je synchronní a nevybírá se, který kanál poskytuje zdroj hodin.Ten ADAT se synchronizuje jako celek.
Ohledně sekání - možná nebyl nastavený default clock na některou z interních frekvencí a když nic nenadetekoval zvenku, tak se švihl.No ten fallback na 48k jsem mu tam nechal. Je možné, že jde o chybu firmware nebo je to potřeba ještě kombinovat s něčím jiným.
Takže jsi přepnul ten registr EMU_HANA_WCLOCK na EMU_HANA_WCLOCK_HANA_SPDIF_IN, pustil do spdif-in nějaký signál a z příslušného vhodně přepnutého capture vstupu nic nelezlo, nebo zkreslené (tedy nesynchronizované)?Přesně tak. Zkoušel jsem to kombinovat i s EMU_HANA_WCLOCK_1X jak to tam má on u těch interních taktů. Hodiny se nepřepnou (respektive hned spadnou zpět do defaultu) a nevydá to ani hlásku. Těžko říct, jestli je to FPGA naprgané tak, aby to zůstalo zamutované dokud se to nepřepne na jeho hodiny nebo je tam ještě nějaká další zrada.
Ještě by se to asi mělo přidat do switche emupcm.c:1256, ale to nevypadá na kritický kód (jenom počet kanálů).To snad mělo být jedno. V mixeru se ten vstup dá routovat na jakýkoliv DSPx.
Řekl bych, že ty interrupty by neměly mít vliv, mělo by to jet stále stejně. Možná to bude jenom signalizace "ADAT zařízení připojeno", asi jako ten DOCK.To si nemyslím. Ty interní takty se nastavují přes tenhle registr, má to svojí logiku.
Je fakt, že bez externích hodin je celé naše snažení o 16 capture kanálů zbytečné.Tak nějak :( Kdyby mi jel ADAT, tak mi celkem i 8 stop stačí (potřebuju snímat bicí). On mimochodem vůbec nefunguje ani ten 24 bit playback. Ale to bych zase nějakou dobu přežil, míchat můžu na audiophile.
To by pak externí hodiny asi vůbec nemohly fungovat :)Proč? Routovat signál ze S/PDIF by to mohlo i na interní hodiny, akorát to buď zalupané nebo totálně zmršené v závislosti na rozdílu těch kmitočtů.
Takže před přepnutím to jede, po přepnutí se vrátí zpět na 48kHz, ale už to nejede?Nejde to nikdy. S/PDIF vstup je permanentně hluchý.
Použití registru EMU_HANA_IRQ_ENABLE jsem ve zdrojácích našel jenom při jeho vynulování (disablování interruptů), nikde jinde. Pak je tam ještě jeho brácha EMU_HANA_IRQ_STATUS, který se jenom čte a vypisuje do debugu. Možná jsem ale něco přehlédl.Myslel jsem ten EMU_HANA_WCLOCK.
Mimochodem, nevíš o nějakém toolu, co by uměl odchytávar registry dané PCI karty? Asi se dám na reverse engineering Spoustu informací je v tom procu, mimo jiné i výpis registrů. Není problém tam přidat další, přijde mi to skoro nejlepší debug nástroj.Šlo mi samozřejmě o sledování chování win driveru ;) S vhodným nástrojem by šlo to přepínání hodin zjistit celkem rychle.
#define EMU_HANA_OPTICAL_TYPE 0x0b /* 00000xx 2 bits ADAT or SPDIF in/out */ #define EMU_HANA_OPTICAL_IN_SPDIF 0x00 #define EMU_HANA_OPTICAL_IN_ADAT 0x01 #define EMU_HANA_OPTICAL_OUT_SPDIF 0x00 #define EMU_HANA_OPTICAL_OUT_ADAT 0x02V main se nakonec nastavuje na spdif-in, ale kdo ví. Ještě by bylo se možná hodilo mrknout při aktivním spdif-in signálu na registr
#define EMU_HANA_SPDIF_MODE 0x0a /* 00xxxxx 5 bits SPDIF MODE */ #define EMU_HANA_SPDIF_MODE_TX_COMSUMER 0x00 #define EMU_HANA_SPDIF_MODE_TX_PRO 0x01 #define EMU_HANA_SPDIF_MODE_TX_NOCOPY 0x02 #define EMU_HANA_SPDIF_MODE_RX_COMSUMER 0x00 #define EMU_HANA_SPDIF_MODE_RX_PRO 0x04 #define EMU_HANA_SPDIF_MODE_RX_NOCOPY 0x08 #define EMU_HANA_SPDIF_MODE_RX_INVALID 0x10jestli se tam něco změní v RX bitech(jsou asi jenom read-only).
Asi jsme si nerozumněli. Pokud by měl čip při externích hodinách vždy zamutované výstupy, pak by celá funkcionalita externích hodin byla k ničemu. Ale takto jsi to asi nemyslel :)Nenene, myslel jsem, že dokud nepřepnu na externí hodiny, tak nemám nárok slyšet něco ze S/PDIF. U mojí audiophile to tak funguje (i když ve starších verzích ovladače šel S/PDIF vstup vždy).
Zkoušel sis hrát s registrem:Jo, to jsem zkoušel přepínat. Ale to se týká jenom ADAT vstupů, které se dají přepnout na optický TOSlink, čímž vznikne druhé S/PDIF. Mě ale zajímá to standardní koaxiální. Ten se dá mimochodem přepnout na AES/EBU, což jsem asi důsledně nezkontroloval (ale výstupní S/PDIF funguje dobře).#define EMU_HANA_OPTICAL_TYPE 0x0b /* 00000xx 2 bits ADAT or SPDIF in/out */ #define EMU_HANA_OPTICAL_IN_SPDIF 0x00 #define EMU_HANA_OPTICAL_IN_ADAT 0x01 #define EMU_HANA_OPTICAL_OUT_SPDIF 0x00 #define EMU_HANA_OPTICAL_OUT_ADAT 0x02V main se nakonec nastavuje na spdif-in, ale kdo ví.
Ještě by bylo se možná hodilo mrknout při aktivním spdif-in signálu na registr jestli se tam něco změní v RX bitech(jsou asi jenom read-only).Vyzkouším.
Bohužel zvuk stále žádný, takže je tam ještě něco v tom routování. Ale pokud rozlouskneme tohle, tak je to asi vyřešené. Ty mraky ifů pro vyšší frekvence budou už běžná nádeničina.
Akorát tím, že tam teď přibyl ten ADAT se zřejmě nějak rozhodilo routování signálu, protože všechno začalo hrát hrozně přebuzeně a hodinama to není. Spíš se tam nějak tlučou 16 bitové BUSy s 32 bitovými.
Super. Stačilo nastavení, nebo jsi dělal nějaké úpravy kódu?Stačilo přepnout optický I/O na ADAT + nastavení registru zdroje hodin. Kdybych býval věděl hned, že nastavení optiky má vliv i na ten koaxiál, ušetřil jsem si práci ;) Taky to vysvětluje zatuhnutí karty při mých dřívějších pokusech o přepnutí zdroje hodin na ADAT vstup. Přepínal jsem to na něco, co v té chvíli neexistovalo.
Jedná se o fyzické vstupy do karty, nebo ty virtuální výstupy přes sběrnici do PC? Potřebovali bychom počty těch virtuálních výstupů, podle kterých můžeme řešit linky z Hany do Alice.Jedná se o vstupy, ze kterých můžu naráz nahrávat a přehrávat do/z DAW. Udělal jsem si tabulku routování. Máme 22 vstupních kanálů z Hany do Alice pojmenované DSP0x0 až DSP0x15 (píšu to tak záměrně, aby se to nepletlo s těmi druhými, které jsou číslované dekadicky). Potom máme 32 kanálů v opačném směru, tedy výstupních, pojmenované DSP0 až DSP31. V mixéru je možné přiřadit každému fyzickému i virtuálnímu "přijámači signálu" (tedy DACy, digitální výstupy a DSP0x0 až DSP0x15) kterýkoliv jeden fyzický nebo virtuální zdroj signálu (tedy ADC, digitální vstupy i DSP0-DSP31 + silence). Tedy můžu například přiřadit k 0202 left DAC vstup 0202 Left S/PDIF IN nebo to vzít oklikou a přiřadit třeba k DSP0x9 kanál 0202 left S/PDIF IN a DSP9 (mapování viz níže) na 0202 left DAC. Mapování mezi vstupními a výstupními DSP je následující: DSP0x0 až DSP0x7 jsou vyhrazené pro nahrávání, nemapují se na DSP0 až DSP7 takže se nedají použít na routování uvnitř Hany. Zato z nich můžu nahrávat v tom multikanálovém režimu. Vyzkoušel jsem nahrávání 8 stop, přičemž na DSP0x0 a DSP0x1 jsem si naroutoval ADC a na DSP0x2 a DSP0x3 S/PDIF vstup a fungovalo to skvěle. Malá zvláštnost je, že ty první dva se v jacku tvářily jako 1. a 8. kanál. Ale jinak spokojenost. DSP0x8 až DSP0x15 jsou namapované rovnoměrně na svoje dekadické kolegy DSP8 až DSP29. Další malá zvláštnost je ta, že pokud si naroutuju S/PDIF vstup na DSP0x12 nebo DSP0x13, tak výstup hraje kromě DSP26 a DSP27 taky z DSP0 a DSP1. Nicméně když namísto S/PDIF použiju ADC, tak se to neděje. Ještě něčím otestuju, jestli je to 24 bit nebo ořezené na 16, ale na to budu potřebovat 24 bit přehrávání.
Akorát tím, že tam teď přibyl ten ADAT se zřejmě nějak rozhodilo routování signálu, protože všechno začalo hrát hrozně přebuzeně a hodinama to není. Spíš se tam nějak tlučou 16 bitové BUSy s 32 bitovými. Na analogovém vstupu přes stejné kanály EMU32 to taky blbne? Co konkrétně myslíš tím "přidal ADAT"?Tak už nic. Jak jsem tu kratu přehazoval zpátky, tak jsem nechal povytažený ten plochý kabel co spojuje 1010 a 0202. Po docvaknutí už to hraje OK.
#define EMU_DST_ALICE2_EMU32_0 0x000f /* 16 EMU32 channels to Alice2 +0 to +0xf */ #define EMU_DST_ALICE2_EMU32_1 0x0000 /* 16 EMU32 channels to Alice2 +0 to +0xf */ #define EMU_DST_ALICE2_EMU32_2 0x0001 /* 16 EMU32 channels to Alice2 +0 to +0xf */Někde jsem četl o více verzích E-MU1212, tak možná je to pro tu druhou verzi. DSP0x8 až DSP0x15 jsou namapované rovnoměrně na svoje dekadické kolegy DSP8 až DSP29. Našel jsi někde ve zdrojáku, kde se to propojuje? To by asi mělo být nastavením těch procesorových instrukcí v alice2 (audigy), ale nikde jsem to nenašel. Možná je to natvrdo ve firmwaru hany. Přepokládám, že jsi to zjistil pokusy. Pokud je to propojené v audigy, pak možná ty filtry popisované v manuálu k win ovladači jsou realizované DSP funkcemi audigy - v headrovém souboru je jich popsána celá řada (i když tam by asi byl problém s vyššími fs). Další malá zvláštnost je ta, že pokud si naroutuju S/PDIF vstup na DSP0x12 nebo DSP0x13, tak výstup hraje kromě DSP26 a DSP27 taky z DSP0 a DSP1. Nicméně když namísto S/PDIF použiju ADC, tak se to neděje. To je hodně divné. Když to SPDIF naroutuješ na jiné než DSP0x12 nebo DSP0x13, tak se to v DSP0/1 neobjeví? Ve zdrojácích se SPDIF vstupy do hany nikde jinde než v tom poli emu1010_src_regs nevyskytují.
Někde jsem četl o více verzích E-MU1212, tak možná je to pro tu druhou verzi.Druhá (tedy současná) verze zřejmě vůbec nefunguje. I když na druhou stranu v alsa firmware někdy před měsícem přibyly definice pro 1010 cardbus (které je identická se současnou 1010 PCI, akorát nemá vyvedené žádné digitální porty) a 1616, takže tam nějaký základ snad bude. Možná je to ta HANA2.
Našel jsi někde ve zdrojáku, kde se to propojuje? To by asi mělo být nastavením těch procesorových instrukcí v alice2 (audigy), ale nikde jsem to nenašel. Možná je to natvrdo ve firmwaru hany. Přepokládám, že jsi to zjistil pokusy.Jojo, udělal jsem si tabulku všech kombinací kromě docku a ADATu. Kde se to propojuje bohužel netuším a o programování emu10k nevím nic. Jediné DSP se kterým jsem koketoval bylo 56001 a to jen velmi mírně a hodně dávno.
Pokud je to propojené v audigy, pak možná ty filtry popisované v manuálu k win ovladači jsou realizované DSP funkcemi audigy - v headrovém souboru je jich popsána celá řada (i když tam by asi byl problém s vyššími fs).Pokud filtry myslíš ty DSP efekty, tak ty jsou pod win použitelné jenom na 44.1/48k. Výš ani ťuk.
Další malá zvláštnost je ta, že pokud si naroutuju S/PDIF vstup na DSP0x12 nebo DSP0x13, tak výstup hraje kromě DSP26 a DSP27 taky z DSP0 a DSP1. Nicméně když namísto S/PDIF použiju ADC, tak se to neděje. To je hodně divné. Když to SPDIF naroutuješ na jiné než DSP0x12 nebo DSP0x13, tak se to v DSP0/1 neobjeví? Ve zdrojácích se SPDIF vstupy do hany nikde jinde než v tom poli emu1010_src_regs nevyskytují.Teď jsem z toho trochu jelen, protože to nemůžu zreplikovat. Přitom včera to dělalo s mými patchi a dneska i s původními hg ovladači. Takže zatím předpokládejme, že nic takového neexistuje.
Takže jestli jsem to dobře pochopil, v základní fs už jedeme kompletně, jenom ještě máme málo vstupů.V zásadě ano. Během příštího týdne si ještě přinesu ten převodník na ADAT, abych zkusil i tohle a v zásadě nevidím důvod proč by to nemělo fungovat. Pak ještě ten playback.
Tam si myslím, že i vyšší DSPxX půjdou vytáhnout, jenom co najdeme to propojení na DSPX. Možná by z toho šlo uddělat flexibilní řešení - počet capture kanálů třeba přes parametr modulu.To je asi zbytečný luxus, který nikdo nevyužije. Každý, kdo si koupí takovouhle chce mít maximální počet vstupů a výstupů přístupný v jacku, kde si to může i přehledně routovat. Stejně tak bych vyhodil všechen ten 16 bit režim, protože je to matoucí a nemá to smysluplné využití.
No právě proto - mluvil jsi přeci o 16 24-bitových capture kanálech ve win, zatímco zde je pouze 8.No to jo, ale nevidím důvod, proč to nastavovat on the fly a přidělávat si tak práci.
Stejně tak bych vyhodil všechen ten 16 bit režim, protože je to matoucí a nemá to smysluplné využití. Který máš konkrétně na mysli?Mám na mysli jakékoliv hw kromě hw0,2 (za předpokladu, že emu1010 je hw0), což je ten 24 bitový capture a (nefunkční) playback. Na hw0,0 je tam šestnáctibitový dvoukanálový režim, co navíc dropoutuje na 44.1kHz, na hw0,3 je nějakej 16 kanálovej capture co jede pouze na 48kHz a ještě něco třetího. To bych dal všechno do pryč.
No to jo, ale nevidím důvod, proč to nastavovat on the fly a přidělávat si tak práci. OK, nemám s tím problém. Třeba to stejně nepůjde zvýšit.Nestraš, ten win ovladač to někudy cpát musí. Přinejmenším se ještě vůbec nevyužívají ty I2S sběrnice.
Najdeš odpovídající definice v emu10k1.c:snd_card_emu10k1_probe + emupcm.c? hw:0,3 by měl být pouze osmikanálový playback "Multichannel Playback". Nesedí mi to ani vůči tomu výpisu procu.Večer na to kouknu. Ten multichannel playbayback nedělá to co má.
Najdeš odpovídající definice v emu10k1.c:snd_card_emu10k1_probe + emupcm.c? hw:0,3 by měl být pouze osmikanálový playback "Multichannel Playback". Nesedí mi to ani vůči tomu výpisu procu.Sorry, napsal jsem nesmysl. Samozřejmě to má být playback. Ale nechová se to jako 8 32 bitových, ale jako 16 16 bitových s tím, že 1. a 5. kanál se mapuje na DSP0, 2. a 6. na DSP1 a ostatní zarytě mlčí. Tak to fungovalo vždycky. Uploadnul jsem výpisy z procu jak jsi chtěl + něco navíc, je to v jednom archívu. Zítra si jdu pro ADAT převodník, tak jsem na to zvědav, ale předpokládám, že to chodit bude. Akorát si nejsem jist, jestli to půjde synchronizovat.
snd_printdd("cr_val=0x%x, cr_val2=0x%x\n", epcm->capture_cr_val, epcm->capture_cr_val2);
K tomu bude zřejmě potřeba zapnout CONFIG_SND_DEBUG_DETECT při kompilaci. Dle dokumentace (Documentation/DocBook/writing-an-alsa-driver.tmpl) je potřeba do configure dát parametr --with-debug=detect . Nebo můžeš místo snd_printdd(X) použít printk(KERN_DEBUG X), to vypíše do dmesg bez další konfigurace.
V současně situaci není audigy přepnuta na 32 capture kanálů a samozřejmě to nemůže fungovat.
if (emu->audigy) {
emu->efx_voices_mask[0] = 0;
///* dustin - zkusime do rezimu write (capture) prepnout dalsich 16 voicu
//emu->efx_voices_mask[1] = 0xffff;
emu->efx_voices_mask[1] = 0xffffffff;
Proměnná capture_cr_val2 se nastavuje jenom zde:
epcm->capture_cr_val2 = emu->efx_voices_mask[1];Položka emu->efx_voices_mask[1] se nastavuje jenom jak výše uvedeno a pak ještě v PCM controlu "Captured FX8010 Outputs" (emupcm.c:snd_emu10k1_pcm_efx_voices_mask_put). Je možné, že výstup toho controlu je uložen někde v alsactl store souboru a po načtení modulu je nové 0xffffffff přepsáno zase na původní 0xffff. Můžeš prosím vyzkoušet nastavit hodnotu tohoto controlu přes amixer? Mělo by být 32 off a 32 on (nyní bude 32off, 16 on, 16 off). Nebo ještě jednodušší řešení - změnit řádek
snd_emu10k1_ptr_write(emu, A_FXWC2, 0, epcm->capture_cr_val2);natvrdo na
snd_emu10k1_ptr_write(emu, A_FXWC2, 0, 0xffffffff);
To přepínání - někde je zřejmě uložený obsah alsactl store (možná dokonce někde v defaultních konfigurácích alsalib - tam jsem to ale nenašel), a po loadnutí modulu se to načte zpět. Nyní dej alsactl store pod rootem a zkus reloadnout ten modul.Tímhle postupem se mi to právě podařilo zapnout. Přes amixer mi to nějak nešlo.
Natvrdo ve zdrojácích by to být nemělo, viděl bych to opravdu na parametr modulu. Ať si každý nastaví, kolik potřebuje, default bych nechal na 8, ať se nerozhodí nějaké aplikace. Zkusím na to mrknout, to by mělo být jednoduché.Popravdě opravdu nevidím důvod, proč tam nenechat natvrdo 16/16. Nenapadá mě jediná aplikace, kde by to něčemu mohlo vadit. Naopak bych se zbavil všech ostatních subdevicí, jak už jsem jednou říkal. IMHO jsou zbytečné a matoucí. 1712 má taky jedniné zařízení s 12/10 I/O a nikomu to nevadí. S RME, Echo a spol. bude situace podobná.
Právě v tom kódu v emufx.c se provádí konverze z 32 bitů na 2x16 bitů, takže by to mělo být v plném rozlišení. Otestoval bych to nahráváním ADC přes některý z EMU32, uložením v 24 bitech a kontrolou přímo datech, že je tam opravdu plné rozlišení 24 bitů a nejde o nějaké 16bit left aligned.To bych si nechal až jako záložní možnost. Chtělo by to nějakou sofistikovanější metodu, kde by zároveň fungovaly testy S/PDIF atd.. Zkusím se zeptat v LAD/LAU, je tam někdo, kdo vyvíjí sadu nástrojů podobnou rightmarku.
Možná by to chtělo pohrát si s parametry buffer_size v alse, přeci jenom přenáší se teď dvakrát tolik dat. Čím vyšší, tím lepší, nebude tolik interruptů.No arecord s tím už měl problémy. Jack to ovšem zvládl na jedničku. A to mám prehistoriský stroj s přetaktovamým athlonem 750 a KT133a čipset s SDRAM.
Ještě by to chtělo otestovat bitovou přesnost (bit-perfect) SPDIF vstupů a výstupů. To by chtělo ještě jednu zvukovku, do ní pustit 24bitový signál a porovnat captured signál - tím se samozřejmě otestuje i 24-bitový příjem.Mám ještě m-audio audiophile (ale ta půjde z domu ;), takže není problém. Ono to ostatně ani jinak nejde, protože 24 bit playback na e-mu nefunguje.
amixer -c 2 cset iface=MIXER,name='Line Playback Volume",index=1 40%Něco jako (neotestované)
for a in `seq 31 63`; do amixer -c cislo_karty cset numid=id,index=$a 1; done
Popravdě opravdu nevidím důvod, proč tam nenechat natvrdo 16/16. Nenapadá mě jediná aplikace, kde by to něčemu mohlo vadit. Naopak bych se zbavil všech ostatních subdevicí, jak už jsem jednou říkal. IMHO jsou zbytečné a matoucí. 1712 má taky jedniné zařízení s 12/10 I/O a nikomu to nevadí. S RME, Echo a spol. bude situace podobná.Obávám se, že není na nás to rozhodnout. Zeptám se v alsa-devel, stejně toho bude více.
No arecord s tím už měl problémy. Jack to ovšem zvládl na jedničku.Tak to bude určitě rozdíl právě ve velikosti bufferu, obojí bude používat stejné API alsy. V arecordu je to parametr --buffer-size=. Ale je to nyní nepodstatné.
Ono to ostatně ani jinak nejde, protože 24 bit playback na e-mu nefunguje.Dáme ještě pár kol :)
Pro testování ovladačů mi přijdou nejlepší, protože nemusím řešit chyby a nestandardní hacky další vrstvy.No já bych řekl, že jack je možná líp otestovanej, než všchny utility z alsy dohromady ;) A hlavně si sám detekuje počet kanálů, formát samplů a v kombinaci s qjackctl mám okamžitý přístup ke každému kanálu a možnost připojit si ho kam chci.
Pustím se tedy do toho patche, informace mám komplet. Rozdělím to na dvě fáze patchování - nejdříve 16 capture + comments, až pak odstranění nepoužívaných PCM, aby to případně šlo revertnout.Souhlas, nicméně jako druhou fázi bych navrhoval spíš 24 bit přehrávání a teprve až to bude chodit, tak vyhodit ostatní PCM ve třetí fázi. Mezitím by se mohl pochlapit James a fixnout inicializaci 1616M, respektive nové revize 1212m :) Safa z audiopro (oficiální ditributor e-mu pro naší republiku) se mě zrovna denska ptal v jaké fázi to je, když jsem mu děkoval za zapůjčení převodníku.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.