From: Michael M. <mih...@ya...> - 2013-06-21 14:47:51
|
Hi Takashi, On 06/21/2013 05:08 PM, Takashi Sakamoto wrote: > Hi Малышев, > > I've also retrieved packet dump of FW 1814. I advice you how to make > it possible to stream it with FFADO. (I'm sorry but I have little time > because of development for ALSA side.) > > M-Audio Firewire 1814 is based on BeBoB chipset of BridgeCo. but the > function is a bit different from the others. this is a very good news. no need to reverse engineering stream format > > 0. To send the magic bytes for loading firmware to bootloader is > needed.[0] > 1. [the same] connection between PC and the device is managed > according to Connection Management Procedure (CMP). [1] > 2. [the same] changing sampling rate is done by INPUT/OUTPUT PLUG > SIGNAL FORMAT command defined in generic AVC.[2] Nice to have right documentation. I will do my best to read it > 3. [the difference] The way to know the formation of data channels in > a data block of AMDTP packets don't exists (but the other BeBoB based > devices have.[3]) > 4. [the difference] AMDTP stream is always in blocking mode. The > number of channels in a data block of AMDTP packets is different > depending on digital format (+1 means MIDI comformant data): > > Receive stream: ADAT SPDIF > 32.0/44.1/48.0 16+1 10+1 > 88.2/96.0 12+1 10+1 > 176.4/192.0 2+1 2+1 > > Transmit stream: ADAT SPDIF > 32.0/44.1/48.0 12+1 6+1 > 88.2/96.0 8+1 6+1 > 176.4/192.0 4+1 4+1 > thank you for this information! > because of 3., the driver should implement this. > > 5. transaction for changing clock and digital format > [FCP transaction] 0x00ff0004 0004WWXX YYZZ(0000: padding) > W: clock source > 0x00: internal (with muted digital channels) > 0x01: external (from digital interface) > 0x02: word clock > 0x03: internal (with unmuted digital channels) > X: digital format for input jack > Y: digital format for output jack > 0x00: SPDIF > 0x01: ADAT > Z: a kind of lock (I don't know exactly) > 0x00: unlocked > 0x01: locked I have figured it out as well. > > But there seems to be no way to retrieve these status from device. I think there is a way to find out : read 84 bytes from ffc1 ffc7 0060 0000 00 00 00 00 00 09 00 04 00 00 00 00 00 00 00 00 ................ 5.0sc 29.1.0 05:59:53.553 mafw 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29.1.16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29.1.32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29.1.48 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 29.1.64 00 00 02 01 .... 29.1.80 last 2 bytes indicate current clock source (02) and lock status (01 -- locked), but i'll double check. Other bytes are signal levels on inputs/outputs > 6. transaction for changing digital interface > [FCP transaction] 0x0008b880 041002XX YY(000000:padding) > XX: for output > YY: for input > 0x00: optical interface > 0x01: coaxial interface > > I think these implementations enable FFADO to drive Firewire 1814 and > I hope you to confirm these. To confirm CMP and FCP, jujuutils is useful. > http://code.google.com/p/jujuutils/ > > Please inform me if you have any questions ;) I will. Thank you for your help! > > [0] > http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user > [1] IEC 61883-1 Consumer audio/video equipment - Digital interface - > Part 1: General > [2] AV/C Digital Interface Command Set Genetal Specification Version > 4.2 (1394TA: Sept 1, 2004) > [3] BridgeCo. Extension for PlugInfo command defined in above AV/C. > http://subversion.ffado.org/browser/trunk/libffado/src/libavc/general/avc_extended_plug_info.cpp > > > > Regards > > Takashi Sakamoto > o-t...@sa... Regards, Michael > > (Jun 21 2013 07:48), Малышев Михаил wrote: >> Hi Everyone, >> >> I have M-Audio FW 1814 and I'm willing to add support for it to FFADO. >> >> Unfortunately I did not have experience with FireWire in the past -- >> it just doesn't exist in embedded world. So I'm looking for some help. >> >> I'm focused on audio playback, recording is the second stage >> >> Here is what I've done last 3 days: >> >> 1. I have captured bus trafic on Windows for device startup sequence >> 2. I know how to set sampling rate >> 3. I know how to set clock source >> 4. I have almost all routing/mixer related register decoded >> >> 5. I have modified firecontrol utility to my needs so I can >> read/write registers in interactive mode >> >> Initialization sequence with my comments and corresponding >> firecontrol commands is attache >> >> So far I met following difficulties >> >> 1. In the attached log there are sequences like this >> >> ffc1 ffff f000 0b00 8 OUT 00 ff 19 00 90 02 ff >> ff ........ 2.1ms >> 0000 ffff f000 0d00 8 IN 0f ff 19 00 90 02 ff >> ff ........ 91ms >> 0000 ffff f000 0d00 8 IN 09 ff 19 00 90 02 ff >> ff ........ 108ms -- time >> delta since previous command >> >> the first command writes 8 bytes to ffc1 ffff f000 0b00 address which >> I believe is command register. The address has sane BUS:NODE >> combination, but following 2 commands have 0000 as BUS:NODE. I'm new >> to iee1394 and I do not know all addressing modes and command modes. >> How is it possible that bus:node set to 0000? How to do the same with >> libraw1394? I have tried raw1394_read(0,0, ....) but it fails >> >> 2. After POR the device is seen as >> >> 1371754801081927: Debug (configrom.cpp)[ 604] printConfigRomDebug: >> Config ROM >> 1371754801081934: Debug (configrom.cpp)[ 605] printConfigRomDebug: >> Current Node Id: 0 >> 1371754801081938: Debug (configrom.cpp)[ 606] printConfigRomDebug: >> GUID: 0x000D6C0410EBDB45 >> 1371754801081941: Debug (configrom.cpp)[ 607] printConfigRomDebug: >> Vendor Name: M-AUDIO >> 1371754801081944: Debug (configrom.cpp)[ 608] printConfigRomDebug: >> Model Name: FW 1814 Bootloader >> 1371754801081947: Debug (configrom.cpp)[ 609] printConfigRomDebug: >> Node Vendor ID: 0x000d6c >> 1371754801081949: Debug (configrom.cpp)[ 610] printConfigRomDebug: >> Model Id: 0x00010070 >> 1371754801081951: Debug (configrom.cpp)[ 611] printConfigRomDebug: >> Unit Specifier ID: 0x00a02d >> 1371754801081954: Debug (configrom.cpp)[ 612] printConfigRomDebug: >> Unit version: 0x00014001 >> 1371754801081956: Debug (configrom.cpp)[ 613] printConfigRomDebug: >> ISO resource manager: 0 >> 1371754801081959: Debug (configrom.cpp)[ 614] printConfigRomDebug: >> Cycle master capable: 0 >> 1371754801081961: Debug (configrom.cpp)[ 615] printConfigRomDebug: >> Bus manager capable: 0 >> 1371754801081964: Debug (configrom.cpp)[ 616] printConfigRomDebug: >> Cycle clock accuracy: 100 >> 1371754801081967: Debug (configrom.cpp)[ 618] printConfigRomDebug: >> Max rec: 8 (max asy payload: 512 bytes) >> >> the device is in bootloader mode. There is a command to switch nodes. >> (step 2) in the log). After the command THE DEVICE generates bus >> reset and now it appears as >> >> 1371763616361939: Debug (configrom.cpp)[ 604] printConfigRomDebug: >> Config ROM >> 1371763616361971: Debug (configrom.cpp)[ 605] printConfigRomDebug: >> Current Node Id: 1 >> 1371763616361980: Debug (configrom.cpp)[ 606] printConfigRomDebug: >> GUID: 0x000D6C0400EBDB45 >> 1371763616361991: Debug (configrom.cpp)[ 607] printConfigRomDebug: >> Vendor Name: M-AUDIO >> 1371763616361999: Debug (configrom.cpp)[ 608] printConfigRomDebug: >> Model Name: FW 1814 >> 1371763616362009: Debug (configrom.cpp)[ 609] printConfigRomDebug: >> Node Vendor ID: 0x000d6c >> 1371763616362016: Debug (configrom.cpp)[ 610] printConfigRomDebug: >> Model Id: 0x00010071 >> 1371763616362027: Debug (configrom.cpp)[ 611] printConfigRomDebug: >> Unit Specifier ID: 0x00a02d >> 1371763616362034: Debug (configrom.cpp)[ 612] printConfigRomDebug: >> Unit version: 0x00014001 >> 1371763616362043: Debug (configrom.cpp)[ 613] printConfigRomDebug: >> ISO resource manager: 1 >> 1371763616362049: Debug (configrom.cpp)[ 614] printConfigRomDebug: >> Cycle master capable: 1 >> 1371763616362064: Debug (configrom.cpp)[ 615] printConfigRomDebug: >> Bus manager capable: 1 >> 1371763616362070: Debug (configrom.cpp)[ 616] printConfigRomDebug: >> Cycle clock accuracy: 100 >> 1371763616362080: Debug (configrom.cpp)[ 618] printConfigRomDebug: >> Max rec: 8 (max asy payload: 512 bytes) >> >> Model ID is changed. And now node 1 is current and can accept commands. >> >> I have not not found any example in libffado code how to deal with >> such devices. How should I implement the driver for this device? I >> need an advice. >> >> 3. I do not know how to correctly test the code I'm writing. I'd like >> to hear 'sin' tone from speakers before I design the full driver, My >> current approach is: >> >> - manually switch the device to 'node 1' , send all command from init >> sequence >> - use ffado-test-streaming as test application. I'm not sure that I'm >> doing right thing at this step. >> >> Any help is really appreciated. >> >> Thanks in advance, >> Michael Malyshev > |