From: Малышев М. <mih...@ya...> - 2013-06-20 23:00:09
Attachments:
fw1814-init.txt
|
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 |
From: Малышев М. <mih...@ya...> - 2013-06-20 23:32:02
Attachments:
fw1814-init.txt
|
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 |
From: Малышев М. <mih...@ya...> - 2013-06-20 22:56:32
Attachments:
fw1814-init.txt
|
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 |
From: Takashi S. <o-t...@sa...> - 2013-06-21 13:09:11
|
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. 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] 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 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 But there seems to be no way to retrieve these status from device. 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 ;) [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... (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 |
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 > |
From: Michael M. <mih...@ya...> - 2013-06-22 16:43:49
|
On 06/21/2013 05:08 PM, Takashi Sakamoto wrote: Hi Takashi, I have some progress with FW 1814. Unfortunatly things are more complicated as I thiught. I found out that following commands put FW1814 to unresponsive state, only power down/up sequence brings it back to life firewire-request /dev/fw1 fcp "01 ff 2f c0 00 00 00 00 ff ff" ExtendedStreamFormatCmd: Request: 0: 01 ff 2f c0 00 00 00 00 ff ff 0: 0x01 AVCCommand ctype ('status') 1: 0xff AVCCommand subunit (subunit_type = 31, subunit_id = 7) 2: 0x2f AVCCommand opcode 3: 0xc0 ExtendedStreamFormatCmd subFunction 4: 0x00 PlugAddress plugDirection 5: 0x00 PlugAddress addressMode 6: 0x00 UnitPlugAddress plugType 7: 0x00 UnitPlugAddress plugId 8: 0xff UnitPlugAddress reserved 9: 0xff ExtendedStreamFormatCmd status firewire-request /dev/fw1 fcp "01 08 2f c0 00 01 00 ff ff ff " ExtendedStreamFormatCmd: Request: 0: 01 08 2f c0 00 01 00 ff ff ff 0: 0x01 AVCCommand ctype ('status') 1: 0x08 AVCCommand subunit (subunit_type = 1, subunit_id = 0) 2: 0x2f AVCCommand opcode 3: 0xc0 ExtendedStreamFormatCmd subFunction 4: 0x00 PlugAddress plugDirection 5: 0x01 PlugAddress addressMode 6: 0x00 SubunitPlugAddress plugId 7: 0xff SubunitPlugAddress reserved0 8: 0xff SubunitPlugAddress reserved1 9: 0xff ExtendedStreamFormatCmd status These are extended plug info commands I commented out cmd.fire() for commands above and discover process went quite far but of curse failed due to extended plug info command failed. Other FCP commands work just fine except one which returns 'not supported' (do not remember each one). I tested FCP both with ffado-test and jujutils. FW1814 accepts commands in any order just after switching from bootloader mode. I'm sill looking through code trying to understand how to workaround the problem with extended plug info command. Should I implement new plug class specially for m-audio bibob? PS: Thank you very much for refernces to document, however I could find only very old draft for [1], [2] is freely available BR, Michael > 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. > > 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] > 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 > > 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 > > But there seems to be no way to retrieve these status from device. > > 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 ;) > > [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... > > (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 > |
From: Takashi S. <o-t...@sa...> - 2013-06-23 01:16:22
|
Hi Michael, > I found out that following commands put FW1814 to unresponsive state, > only power down/up sequence brings it back to life Yes. We can't send some command which FW1814 don't deal. But I think current FFADP implementation is based on "try and error". > PS: Thank you very much for refernces to document, however I could find > only very old draft for [1], [2] is freely available I forgot to add "[4] IEC 61883-6:2005 Consumer audio/video equipment - Digital interface - Part 6: Audio and music data transmission protocol. For IEC's spec, we can buy it at IEC webstore. But for 1394TA's, we need to join in the alliance (and it's not reasonable for us). But actually you work with BeBoB chip. Most implementation is done by FFADO developers (and I respect their work). So it's enough you arrange the current codes for Firewire 1814. > I'm sill looking through code trying to understand how to workaround the > problem with extended plug info command. Should I implement new plug > class specially for m-audio bibob? BeBoB ;) I know the windows driver and FW1814 don't use the "Extended Plug Info" and "Extended Stream Format". So I think it good to implement "what to know via these command" inner FFADO. For your information: M-Audio Firewire 1814 http://ubuntuone.com/3zTih5tzC1xOGBO3YYShxw M-Audio Firewire 410 http://ubuntuone.com/4SgDvAJGFJKKKBAhdV6yJw M-Audio Solo http://ubuntuone.com/2VwLcQ272fjbxBnsFZYcS8 M-Audio Audiophile http://ubuntuone.com/3sPYTc1ssZ3x3bW2AIBok8 Yamaha Go44 http://ubuntuone.com/63c4Q1aEVaFrTDWx5IzX7D Yamaha Go46 http://ubuntuone.com/5ggByVkxPQScWIefoYUVjs Regards Takashi Sakamoto o-t...@sa... (Jun 23 2013 01:43), Michael Malyshev wrote: > On 06/21/2013 05:08 PM, Takashi Sakamoto wrote: > > Hi Takashi, > > I have some progress with FW 1814. Unfortunatly things are more > complicated as I thiught. > > I found out that following commands put FW1814 to unresponsive state, > only power down/up sequence brings it back to life > > firewire-request /dev/fw1 fcp "01 ff 2f c0 00 00 00 00 ff ff" > > ExtendedStreamFormatCmd: > Request: > 0: 01 ff 2f c0 00 00 00 00 ff ff > 0: 0x01 AVCCommand ctype ('status') > 1: 0xff AVCCommand subunit (subunit_type = 31, subunit_id = 7) > 2: 0x2f AVCCommand opcode > 3: 0xc0 ExtendedStreamFormatCmd subFunction > 4: 0x00 PlugAddress plugDirection > 5: 0x00 PlugAddress addressMode > 6: 0x00 UnitPlugAddress plugType > 7: 0x00 UnitPlugAddress plugId > 8: 0xff UnitPlugAddress reserved > 9: 0xff ExtendedStreamFormatCmd status > > > firewire-request /dev/fw1 fcp "01 08 2f c0 00 01 00 ff ff ff " > > > ExtendedStreamFormatCmd: > Request: > 0: 01 08 2f c0 00 01 00 ff ff ff > 0: 0x01 AVCCommand ctype ('status') > 1: 0x08 AVCCommand subunit (subunit_type = 1, subunit_id = 0) > 2: 0x2f AVCCommand opcode > 3: 0xc0 ExtendedStreamFormatCmd subFunction > 4: 0x00 PlugAddress plugDirection > 5: 0x01 PlugAddress addressMode > 6: 0x00 SubunitPlugAddress plugId > 7: 0xff SubunitPlugAddress reserved0 > 8: 0xff SubunitPlugAddress reserved1 > 9: 0xff ExtendedStreamFormatCmd status > > These are extended plug info commands > > I commented out cmd.fire() for commands above and discover process went > quite far but of curse failed due to extended plug info command failed. > > Other FCP commands work just fine except one which returns 'not > supported' (do not remember each one). I tested FCP both with ffado-test > and jujutils. FW1814 accepts commands in any order just after switching > from bootloader mode. > > I'm sill looking through code trying to understand how to workaround the > problem with extended plug info command. Should I implement new plug > class specially for m-audio bibob? > > PS: Thank you very much for refernces to document, however I could find > only very old draft for [1], [2] is freely available > > BR, > Michael > >> 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. >> >> 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] >> 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 >> >> 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 >> >> But there seems to be no way to retrieve these status from device. >> >> 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 ;) >> >> [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... |
From: Daniel W. <wa...@mo...> - 2013-06-29 19:00:21
|
Hi, Sorry was on vacation, therefore I saw these messages a bit late. Maybe I can shed some light on the topic. On 06/23/2013 03:16 AM, Takashi Sakamoto wrote: > But actually you work with BeBoB chip. Most implementation is done by > FFADO developers (and I respect their work). So it's enough you arrange > the current codes for Firewire 1814. > > > I'm sill looking through code trying to understand how to workaround the > > problem with extended plug info command. Should I implement new plug > > class specially for m-audio bibob? > > BeBoB ;) > I know the windows driver and FW1814 don't use the "Extended Plug Info" > and "Extended Stream Format". So I think it good to implement "what to > know via these command" inner FFADO. So the FW1814 and also FW410 are based on a early version of the BeBoB firmware. Also M-Audio requested the special behaviour on the bootup you have noticed to be added to the firmware. The FW1814/FW410 will boot on default into the bootloader mode. The magic command string you need to send, is nothing else, then telling the bootloader to load the firmware stored in the flash chips. If you are able to solder a bit you can add some pins an attached them to a null modem cabel. Then you can see via the serial terminal whats happening on the device. There is even a simple shell which allows you to reconfigure etc the device. I also tried to get the FW410 working but didn't get to far. There was something going pretty wrong pretty early on. I can't remember the details and I don't have any device to play with at this point. I'll check my notes if I can find anything useful. BTW, it is really nice that someone is working on these devices! Thanks! cheers, daniel |
From: Stefan R. <st...@s5...> - 2013-06-21 07:51:21
|
On Jun 21 Малышев Михаил wrote: > Hi Everyone, > > I have M-Audio FW 1814 and I'm willing to add support for it to FFADO. Have a look at thread "[FFADO-user] a work around for Firewire Audiophile and 410 (M-Audio)". http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user Maybe you can adapt some of this to your device. [...] > 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 [...] I haven't looked at your log yet. However, you are correct that 0000 as BUS:NODE is bogus; this is a remote address to be used together with IEEE 1394.1 bus bridges (of which I know no actual hardware or software implementation). All asynchronous traffic should be addressed to the local bus, i.e. have ffc0 | phyID as topmost bytes of the 64 bit address. Anyway; it seems that in this session phyID 1 is the FW 1814 and phyID 0 is the controlling PC. The first of the packets is probably a write request from the PC to the FW 1814's FCP_COMMAND register. The two other packets are probably write requests from the FW 1814 to the PC's FCP_RESPONSE register. This pair of registers is used in a split transaction based transport protocol called Function Control Protocol (FCP), defined in IEC 61883-1. An FCP request is implemented as an IEEE 1394 write request from the FCP requester to the FCP_REQUEST register at ffff f000 0b00 of the FCP responder. An FCP response is implemented as an IEEE 1394 write request from the FCP responder to the FCP_RESPONSE register at ffff f000 0c00 of the FCP requester. libraw1394 supports FCP in the following way: - To send FCP requests (if you implement an FCP requester) or to send FCP responses (if you implement an FCP responder), simply use the generic IEEE 1394 write request functions of libraw1394. - To receive FCP responses (if you implement an FCP requester) or to receive FCP requests (if you implement an FCP responder), use libraw1394's FCP related functions. Basically, - register an FCP event handler with libraw1394's event loop, - start listening for FCP events, - process the event loop, - stop listening for FCP events. However, maybe you don't actually have to delve into all this but can proceed to work at a higher level with libffado instead of libraw1394 once you managed to initialize the FW 1814 firmware. Another word about FCP: I called it a transport protocol because the FCP specification itself does not define any particular command set. Different command sets can be carried over FCP. Most prominent is the AV/C family of command sets which are defined in various AV/C specifications published by 1394TA. Besides the commands that are define in the 1394TA specifications, vendors may add custom AV/C commands at their leisure. In addition, vendors may use a custom non-AV/C command set over FCP. (Or vendors may not use FCP at all, but FW 1814 evidently does use FCP to some extent.) -- Stefan Richter -=====-===-= -==- =-=-= http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ju...> - 2013-06-21 09:34:09
|
On Fri, Jun 21, 2013 at 09:51:09AM +0200, Stefan Richter wrote: > > 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 > [...] > > I haven't looked at your log yet. However, you are correct that 0000 as > BUS:NODE is bogus; this is a remote address to be used together with IEEE > 1394.1 bus bridges (of which I know no actual hardware or software > implementation). All asynchronous traffic should be addressed to the > local bus, i.e. have ffc0 | phyID as topmost bytes of the 64 bit address. > > Anyway; it seems that in this session phyID 1 is the FW 1814 and phyID 0 > is the controlling PC. The first of the packets is probably a write > request from the PC to the FW 1814's FCP_COMMAND register. The two other > packets are probably write requests from the FW 1814 to the PC's > FCP_RESPONSE register. > > This pair of registers is used in a split transaction based transport > protocol called Function Control Protocol (FCP), defined in IEC 61883-1. > An FCP request is implemented as an IEEE 1394 write request from the > FCP requester to the FCP_REQUEST register at ffff f000 0b00 of the > FCP responder. An FCP response is implemented as an IEEE 1394 write request > from the FCP responder to the FCP_RESPONSE register at ffff f000 0c00 of > the FCP requester. This talk about an FCP transaction in combination with a few indirect comments I've seen on the net lead to to at least ask this question: is the M-Audio FW 1814 based on the DICE chipset? If it is, most of the work may already be handled by libffado. Sure, there could be some vendor-specific details which need to be filled in, but the generic code would at least give you a good head-start. The easiest way to determine what the situation is would be to obtain the vendor and model ID of the FW-1814 using gscanbus (or something similar), plugging these into a new entry in the file named "configuration" used by FFADO, installing this (if necessary) and seeing what happens. If you post the vendor/model IDs we can even check these in to the repo in the event the DICE driver at least sort of works. > However, maybe you don't actually have to delve into all this but can > proceed to work at a higher level with libffado instead of libraw1394 > once you managed to initialize the FW 1814 firmware. Yes, this is what I was thinking. > Besides the commands that are define in the 1394TA specifications, vendors > may add custom AV/C commands at their leisure. In addition, vendors may > use a custom non-AV/C command set over FCP. (Or vendors may not use FCP > at all, but FW 1814 evidently does use FCP to some extent.) This is the potential trap. If we're lucky the FW-1814 follows the standard command set closely and little additional work will be needed in libffado to get it working. At the other end of the scale, M-Audio might have used an entirely different command set, in which case a new driver (still using the FCP framework) would need to be added to ffado. Regards jonathan |
From: Малышев М. <mih...@ya...> - 2013-06-21 11:15:46
|
> However, maybe you don't actually have to delve into all this but can > proceed to work at a higher level with libffado instead of libraw1394 > once you managed to initialize the FW 1814 firmware. I'd love to proceed with higher level. I looked into ffado code for last 3 days and still do not have full undrstanding of its structure and more important function call flow. Let's imagine I did these things 1. Added device to 'configuration' and set driver to 'm-audio' (5) 2. modified maudio_avdevice.cpp and reinstalled how to test it? are there any ready to use test apps for this or at least the app I can use as base for my own test app? > The easiest way to determine what the situation is would be to obtain the > vendor and model ID of the FW-1814 using gscanbus (or something similar), > plugging these into a new entry in the file named "configuration" used by > FFADO, installing this (if necessary) and seeing what happens. If you post > the vendor/model IDs we can even check these in to the repo in the event the > DICE driver at least sort of works. > these are config ROM dumps from my initial email for both nodes --- bootloader--- Current Node Id: 0 GUID: 0x000D6C0410EBDB45 Vendor Name: M-AUDIO Model Name: FW 1814 Bootloader Node Vendor ID: 0x000d6c Model Id: 0x00010070 Unit Specifier ID: 0x00a02d Unit version: 0x00014001 ISO resource manager: 0 Cycle master capable: 0 Bus manager capable: 0 Cycle clock accuracy: 100 Max rec: 8 (max asy payload: 512 bytes) ---- FW 1814 Audio ------ Current Node Id: 1 GUID: 0x000D6C0400EBDB45 Vendor Name: M-AUDIO Model Name: FW 1814 Node Vendor ID: 0x000d6c Model Id: 0x00010071 Unit Specifier ID: 0x00a02d Unit version: 0x00014001 ISO resource manager: 1 Cycle master capable: 1 Bus manager capable: 1 Cycle clock accuracy: 100 Max rec: 8 (max asy payload: 512 bytes) The catch is the device starts in 'bootloader' mode after power-on-reset and has to be switched to 'FW 1814' mode by special command which I can send manually using is using simple utility 'fireconntrol' with my modifications to send variable length block w . 0x0 0xffffc8021000 12 0x1 0x00 0x00 0x00 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 exactly the same procedure is described in http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user (thanks Stefan!) now we can say for sure that both WF410 and FW 1814 follow the same start-up procedure. I'll try to send FCP commands today when I'll get home I also looked into FW1814 firmware dump and I can see a lot of debug messages inside. There must be serial console somethere on PCB. I'm going to disassemble my device and find the console test points Looking into FW410 firmware I can see a lot of references to 'BeBob' but there are none of them in FW1814 dump. BR, Michael Malyshev |
From: Jonathan W. <jw...@ju...> - 2013-06-21 11:28:51
|
On Fri, Jun 21, 2013 at 02:56:35PM +0400, ??????? ?????? wrote: > > However, maybe you don't actually have to delve into all this but can > > proceed to work at a higher level with libffado instead of libraw1394 > > once you managed to initialize the FW 1814 firmware. > I'd love to proceed with higher level. I looked into ffado code for last 3 > days and still do not have full undrstanding of its structure and more > important function call flow. Let's imagine I did these things > > 1. Added device to 'configuration' and set driver to 'm-audio' (5) > 2. modified maudio_avdevice.cpp and reinstalled > > how to test it? are there any ready to use test apps for this or at least > the app I can use as base for my own test app? The easiest way to test it would be via ffado-test in the first instance. Once that program was shown to deal with the device initialisation correctly you could move on to using FFADO via JACK to test the audio streaming: jackd -d firewire for example. The primary way of using interfaces supported by FFADO is through JACK. JACK is a framework which allows applications and audio hardware to send audio freely between themselves. When the JACK server (jackd) is running, your "test app" would simply connect to jackd in the same way as any other jack-enabled audio program. For more information about jack, check out that project's website at http://www.jack-audio.org You mentioned the maudio_avdevice.cpp module. This is aimed primarily at the FW-410 device which is based on the BeBoB chipset. We suspect that the FW-1814 is based on DICE, so a separate driver would be needed. However, this would not be needed initially: at this early stage all you want to do is see how far the generic DICE code gets with this interface. So creating a configuration entry like the following is probably enough to get you started: { # M-Audio FW-1814 vendorid = 0x000d6c; modelid = 0x00010071; vendorname = "M-Audio"; modelname = "FW-1814"; driver = 20; # DICE mixer = "Generic_Dice_EAP"; }, > > The easiest way to determine what the situation is would be to obtain the > > vendor and model ID of the FW-1814 using gscanbus ... > these are config ROM dumps from my initial email for both nodes > : Apologies - I forgot you'd included these earlier. > The catch is the device starts in 'bootloader' mode after power-on-reset > and has to be switched to 'FW 1814' mode by special command which I can > send manually using is using simple utility 'fireconntrol' with my > modifications to send variable length block Right. That is different to most other interfaces. However, I don't think it would be difficult to accommodate this within ffado. There may be a need to include a configuration entry with the "boot loader" model ID (0x00010070) in addition to the main one. Then if the FW1814 probe/discover methods detected this they could arrange to send the special command at that point. After delaying for a suitable time it could then retry the probe to find the initialised FW-1814. It may even be possible to have the initialisation command in the probe() method so that by the time discover() is called the interface is ready to go. > exactly the same procedure is described in > http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user > (thanks Stefan!) > > now we can say for sure that both WF410 and FW 1814 follow the same > start-up procedure. Since the FW-410 is BoBob-based, perhaps this indicates that the FW-1814 is also a BeBob device. If true, my comment above about the maudio_avdevice.cpp module is not true and it would be the applicable place to put FW-1814 code. However, M-Audio could easily have used the same startup sequence for both regardless of the underlying chipset. > I also looked into FW1814 firmware dump and I can see a lot of debug > messages inside. There must be serial console somethere on PCB. I'm going > to disassemble my device and find the console test points That might show up something interesting. > Looking into FW410 firmware I can see a lot of references to 'BeBob' but > there are none of them in FW1814 dump. This may indicate that the FW-1814 is not a BoBob device - perhaps it's DICE, or maybe it's something else entirely different. Regards jonathan |
From: Clemens L. <cl...@la...> - 2013-06-21 13:08:50
|
Jonathan Woithe wrote: > [...] > the FW-410 device which is based on the BeBoB chipset. We suspect that the > FW-1814 is based on DICE DICE would not use FCP. And I doubt that the DICE chip would have a "bridgeCo" label: <http://soundbuilders.lvl1.org/uploads/FileUpload/10/10.JPG> > { # M-Audio FW-1814 > vendorid = 0x000d6c; > modelid = 0x00010071; > vendorname = "M-Audio"; > modelname = "FW-1814"; > driver = 20; # DICE > mixer = "Generic_Dice_EAP"; { vendorid = 0x000d6c; modelid = 0x00010071; vendorname = "M-Audio"; modelname = "FW-1814"; driver = 1; # BeBoB xmit_max_cycles_early_transmit = 4; }, Regards, Clemens |
From: Michael M. <mih...@ya...> - 2013-06-21 13:57:50
|
On 06/21/2013 03:28 PM, Jonathan Woithe wrote: > On Fri, Jun 21, 2013 at 02:56:35PM +0400, ??????? ?????? wrote: >>> However, maybe you don't actually have to delve into all this but can >>> proceed to work at a higher level with libffado instead of libraw1394 >>> once you managed to initialize the FW 1814 firmware. >> I'd love to proceed with higher level. I looked into ffado code for last 3 >> days and still do not have full undrstanding of its structure and more >> important function call flow. Let's imagine I did these things >> >> 1. Added device to 'configuration' and set driver to 'm-audio' (5) >> 2. modified maudio_avdevice.cpp and reinstalled >> >> how to test it? are there any ready to use test apps for this or at least >> the app I can use as base for my own test app? > The easiest way to test it would be via ffado-test in the first instance. > Once that program was shown to deal with the device initialisation correctly > you could move on to using FFADO via JACK to test the audio streaming: > > jackd -d firewire > > for example. The primary way of using interfaces supported by FFADO is > through JACK. JACK is a framework which allows applications and audio > hardware to send audio freely between themselves. When the JACK server > (jackd) is running, your "test app" would simply connect to jackd in the > same way as any other jack-enabled audio program. > > For more information about jack, check out that project's website at > > http://www.jack-audio.org Ideally I need another FireWire interface supported by FFADO in order to make sure the chain "Audio Player App -> JACKD -> FFADO -> FireWire Audio Interface -> Speakers" works fine I knew about jackd, however I never used it before. And since I do not have other FW Audio device I did not want to add additional layers which may introduce any 'instability' in the chain . That is why I was asking about the possibility to test my code on the lowest possible layer (ffado driver). I noticed that ffado-test-streaming has options to generate sin wave and stream it , but Looking into the log I did not see that all expected functions of my driver are called when running ffado-test-streaming. The first function in the sequence is getSupportedSamplingFrequencies() where I return the vector of supported freqs. Then setSamplingFrequency(44100) is called but before this I have to send some commands to FW1814 in order to setup routing/mixer. I need to find a suitable place to put FW1814 initialization code. this is just the matter of time while I'm learning the code. > > You mentioned the maudio_avdevice.cpp module. This is aimed primarily at > the FW-410 device which is based on the BeBoB chipset. We suspect that the but the support of switching modes is not in the trunk still. Your suggestion bellow about new parameter bootloadr_model_id should make life easier for both FW410 and FW1814. I think I'll start with this task. I'll get easier test procedure for 1814 and users of 410 will get support out-of-the-box btw, I do not see FW410 in 'configuration' file and it is marked as 'reported to be working' on ffado web site. So there is no out-of-the-box support for FW410, right? > FW-1814 is based on DICE, so a separate driver would be needed. However, > this would not be needed initially: at this early stage all you want to do > is see how far the generic DICE code gets with this interface. So creating > a configuration entry like the following is probably enough to get you > started: > > { # M-Audio FW-1814 > vendorid = 0x000d6c; > modelid = 0x00010071; > vendorname = "M-Audio"; > modelname = "FW-1814"; > driver = 20; # DICE > mixer = "Generic_Dice_EAP"; > }, I'll check it today. Will be great if this is DICE based device. >>> The easiest way to determine what the situation is would be to obtain the >>> vendor and model ID of the FW-1814 using gscanbus ... >> these are config ROM dumps from my initial email for both nodes >> : > Apologies - I forgot you'd included these earlier. > >> The catch is the device starts in 'bootloader' mode after power-on-reset >> and has to be switched to 'FW 1814' mode by special command which I can >> send manually using is using simple utility 'fireconntrol' with my >> modifications to send variable length block > Right. That is different to most other interfaces. However, I don't think > it would be difficult to accommodate this within ffado. There may be a need > to include a configuration entry with the "boot loader" model ID > (0x00010070) in addition to the main one. Then if the FW1814 probe/discover > methods detected this they could arrange to send the special command at that > point. After delaying for a suitable time it could then retry the probe to > find the initialised FW-1814. It may even be possible to have the > initialisation command in the probe() method so that by the time discover() > is called the interface is ready to go. I like the idea about additional parameter. I think it is easier and more reliable to handle 'bus reset' than sleep() for some time. 'bus reset' will be generated because the topology is changed. There is a function virtual bool FFADODevice::needsRediscovery(); which may be used I think to infrom that rediscovery is required after bus reset. ffad-test Discover is the right command for testing, isn't it? > >> exactly the same procedure is described in >> http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user >> (thanks Stefan!) >> >> now we can say for sure that both WF410 and FW 1814 follow the same >> start-up procedure. > Since the FW-410 is BoBob-based, perhaps this indicates that the FW-1814 is > also a BeBob device. If true, my comment above about the > maudio_avdevice.cpp module is not true and it would be the applicable place > to put FW-1814 code. However, M-Audio could easily have used the same > startup sequence for both regardless of the underlying chipset. I think it just mean that m-audio uses the same bootloader. The platform may be different > >> I also looked into FW1814 firmware dump and I can see a lot of debug >> messages inside. There must be serial console somethere on PCB. I'm going >> to disassemble my device and find the console test points > That might show up something interesting. > >> Looking into FW410 firmware I can see a lot of references to 'BeBob' but >> there are none of them in FW1814 dump. > This may indicate that the FW-1814 is not a BoBob device - perhaps it's > DICE, or maybe it's something else entirely different. > > Regards > jonathan |
From: Jonathan W. <jw...@ju...> - 2013-06-21 14:35:29
|
Hi Michael On Fri, Jun 21, 2013 at 05:42:18PM +0400, Michael Malyshev wrote: > On 06/21/2013 03:28 PM, Jonathan Woithe wrote: > >On Fri, Jun 21, 2013 at 02:56:35PM +0400, ??????? ?????? wrote: > Ideally I need another FireWire interface supported by FFADO in > order to make sure the chain > > "Audio Player App -> JACKD -> FFADO -> FireWire Audio Interface -> > Speakers" works fine Not really. Each device is different and having another firewire interface working won't really prove much. So long as you have a known good firewire chipset in your computer you should be good to go. Jackd can also talk to ALSA cards, of which there is one on every mainboard these days. This would give you a way to test the "Audio Player App -> JACKD" part of your flow chart if you wanted to confirm that much. > I knew about jackd, however I never used it before. And since I do > not have other FW Audio device I did not want to add additional > layers which may introduce any 'instability' in the chain . That is > why I was asking about the possibility to test my code on the lowest > possible layer (ffado driver). Aside from the simple test programs which come with ffado, jackd is the only known client of libffado. There's no reason why you couldn't write something which used libffado directly but this would limit you to firewire audio interfaces. By going via jack you immediately make your application usable on virtually any audio interface: firewire or anything supported by ALSA. > I noticed that ffado-test-streaming has options to generate sin wave and > stream it ... Many of the ffado test programs were designed to exercise the internal infrastructure of ffado. They may have limited utility when debugging drivers. To be honest I've hardly used any of them so I'm not sure how useful they will be. > ... but Looking into the log I did not see that all expected functions of > my driver are called when running ffado-test-streaming. > > The first function in the sequence is > getSupportedSamplingFrequencies() where I return the vector of > supported freqs. Then setSamplingFrequency(44100) is called but > before this I have to send some commands to FW1814 in order to setup > routing/mixer. I need to find a suitable place to put FW1814 > initialization code. There are a number of additional calls behind the scenes which form part of the basic FFADO infrastructure. When FFADO starts up it probes the firewire bus for possible devices. An instance of each driver object is created (which causes the constructor to be called) and the probe() method is called to see if the device matches one that the driver object can deal with. If not, the object is disposed of (causing the destructor to be called). If not, the discover() method is called to further identify the device and set up details like the dbus mixer controls. At that point the driver object is ready for use: either for streaming audio (as used by jackd) or to control the device (via ffado-dbus-server and ffado-mixer). Let's take the MOTU driver as an example. When the MOTU driver object is created MotuDevice::MotuDevice() is called. In this driver the constructor does little more than initialise some data fields. MotuDevice::probe() is then called to test whether the detected device is one that the MotuDevice driver object knows how to drive. If not this function returns "false" to indicate to the caller that the search should continue. Otherwise "true" is returned. Soon after, MotuDevice::discover() is called to formally discover the device and initialise anything which needs setting up in order to use the device. It is at this point that other device functions can be called to initiate streaming or a mixer interface. In the case of ffado-test-streaming (source is teststreaming3.cpp), most of the above steps are taken care of as a result of calling ffado_streaming_init(). I haven't thought too much about it, but I expect that the magic initialisation sequence would probably be sent from the probe() method after identifying that the device is an applicable M-Audio device. Some care may be needed to deal with the resulting bus reset, but I think that would be doable - it just needs some thought. > >You mentioned the maudio_avdevice.cpp module. This is aimed primarily at > >the FW-410 device which is based on the BeBoB chipset. We suspect that the > but the support of switching modes is not in the trunk still. Your > suggestion bellow about new parameter bootloadr_model_id should make > life easier for > both FW410 and FW1814. I think I'll start with this task. I'll get > easier test procedure for 1814 and users of 410 will get support > out-of-the-box Absolutely, the magic activation has not yet been implemented. However - and although I haven't thought it through fully yet - I expect the existing infrastructure will be able to cope without having to refactor it completely. > btw, I do not see FW410 in 'configuration' file and it is marked as > 'reported to be working' on ffado web site. So there is no > out-of-the-box support for FW410, right? Something's not quite right there. If it's not in the configuration file then I can't see how it can be working for anyone. Something seems to be confused. I would be interested to find out why the FW-410 is reported to work. > >FW-1814 is based on DICE ... > > I'll check it today. Will be great if this is DICE based device. As per an earlier post and a reference to a photo inside the box, it seems that the FW-1814 is most likely a BoBoB device like the FW-410. > I like the idea about additional parameter. I think it is easier and > more reliable to handle 'bus reset' than sleep() for some time. 'bus > reset' will be generated because the topology is changed. There is a > function virtual bool FFADODevice::needsRediscovery(); which may be > used I think to infrom that rediscovery is required after bus reset. I'm not sure of exactly how this will look - it needs some thought. In particular I'm not sure what effect a bus reset will have on the Device object if it occurs in the middle of the probe() call. If the boot loader is handled from probe() there *may* not be any need for a needsRediscovery() method; discover() could be called subsequently on the assumption that probe() has already kicked the device into action. > ffad-test Discover is the right command for testing, isn't it? Yes, "ffado-test Discover" exercises the device probe and discovery code paths. I would expect it to be sufficient for testing the future mode switching and device discovery functionality because that would all be rolled into this phase of FFADO's operation. > >>exactly the same procedure is described in > >>http://sourceforge.net/mailarchive/forum.php?thread_name=5187BDB2.8030705%40sakamocchi.jp&forum_name=ffado-user > >>(thanks Stefan!) > >> > >>now we can say for sure that both WF410 and FW 1814 follow the same > >>start-up procedure. > : > I think it just mean that m-audio uses the same bootloader. The > platform may be different True, but evidence cited by Clemens indicates that the FW-1814 is based on BeBoB. Regards jonathan |
From: Michael M. <mih...@ya...> - 2013-06-21 14:14:53
|
On 06/21/2013 05:08 PM, Clemens Ladisch wrote: > Jonathan Woithe wrote: >> [...] >> the FW-410 device which is based on the BeBoB chipset. We suspect that the >> FW-1814 is based on DICE > DICE would not use FCP. Thank you for advice. Takashi Sakamoto says it is definitely DeBoB based device Unfortunately I'm new to all of these, need time to catch up > > And I doubt that the DICE chip would have a "bridgeCo" label: > <http://soundbuilders.lvl1.org/uploads/FileUpload/10/10.JPG> > >> { # M-Audio FW-1814 >> vendorid = 0x000d6c; >> modelid = 0x00010071; >> vendorname = "M-Audio"; >> modelname = "FW-1814"; >> driver = 20; # DICE >> mixer = "Generic_Dice_EAP"; > { > vendorid = 0x000d6c; > modelid = 0x00010071; > vendorname = "M-Audio"; > modelname = "FW-1814"; > driver = 1; # BeBoB > xmit_max_cycles_early_transmit = 4; > }, > > > Regards, > Clemens |
From: Michael M. <mih...@ya...> - 2013-06-21 14:19:22
|
On 06/21/2013 06:14 PM, Michael Malyshev wrote: > On 06/21/2013 05:08 PM, Clemens Ladisch wrote: >> Jonathan Woithe wrote: >>> [...] >>> the FW-410 device which is based on the BeBoB chipset. We suspect that the >>> FW-1814 is based on DICE >> DICE would not use FCP. > Thank you for advice. Takashi Sakamoto says it is definitely DeBoB based > device > > Unfortunately I'm new to all of these, need time to catch up >> And I doubt that the DICE chip would have a "bridgeCo" label: >> <http://soundbuilders.lvl1.org/uploads/FileUpload/10/10.JPG> Since you already disassembled the device, could you look around and try to find some test points or sockets labeled 'debug', 'console', 'uart' or something like this? Looking into firmware dump I'm sure there is an interactive shell which might be very useful for further reverse engineering BR, Michael >> >>> { # M-Audio FW-1814 >>> vendorid = 0x000d6c; >>> modelid = 0x00010071; >>> vendorname = "M-Audio"; >>> modelname = "FW-1814"; >>> driver = 20; # DICE >>> mixer = "Generic_Dice_EAP"; >> { >> vendorid = 0x000d6c; >> modelid = 0x00010071; >> vendorname = "M-Audio"; >> modelname = "FW-1814"; >> driver = 1; # BeBoB >> xmit_max_cycles_early_transmit = 4; >> }, >> >> >> Regards, >> Clemens > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Clemens L. <cl...@la...> - 2013-06-21 14:29:48
|
Michael Malyshev wrote: >> On 06/21/2013 05:08 PM, Clemens Ladisch wrote: >>> And I doubt that the DICE chip would have a "bridgeCo" label: >>> <http://soundbuilders.lvl1.org/uploads/FileUpload/10/10.JPG> > > Since you already disassembled the device, I just made a Google search ... Regards, Clemens |
From: Stefan R. <st...@s5...> - 2013-06-21 14:46:21
|
On Jun 21 Michael Malyshev wrote: > >> The catch is the device starts in 'bootloader' mode after power-on-reset > >> and has to be switched to 'FW 1814' mode by special command which I can > >> send manually using is using simple utility 'fireconntrol' with my > >> modifications to send variable length block > > Right. That is different to most other interfaces. However, I don't think > > it would be difficult to accommodate this within ffado. There may be a need > > to include a configuration entry with the "boot loader" model ID > > (0x00010070) in addition to the main one. Then if the FW1814 probe/discover > > methods detected this they could arrange to send the special command at that > > point. After delaying for a suitable time it could then retry the probe to > > find the initialised FW-1814. It may even be possible to have the > > initialisation command in the probe() method so that by the time discover() > > is called the interface is ready to go. > I like the idea about additional parameter. I think it is easier and > more reliable to handle 'bus reset' than sleep() for some time. 'bus > reset' will be generated because the topology is changed. There is a > function virtual bool FFADODevice::needsRediscovery(); which may be > used I think to infrom that rediscovery is required after bus reset. The boot loader trigger could be a small stand-alone utility plus an udev rule which invokes this utility when the boot loader vendor:model IDs shows up in an 'add' uevent. Alternatively, this could be implemented as a tiny kernel module. This doesn't make much sense at this point in time, but could make some sense if a BeBoB ALSA streaming driver (with M-Audio stream format support) is being added to the kernel too. -- Stefan Richter -=====-===-= -==- =-=-= http://arcgraph.de/sr/ |
From: Jonathan W. <jw...@ju...> - 2013-06-21 14:52:21
|
On Fri, Jun 21, 2013 at 04:45:52PM +0200, Stefan Richter wrote: > On Jun 21 Michael Malyshev wrote: > > >> The catch is the device starts in 'bootloader' mode after power-on-reset > > >> and has to be switched to 'FW 1814' mode by special command which I can > > >> send manually using is using simple utility 'fireconntrol' with my > > >> modifications to send variable length block > > > Right. That is different to most other interfaces. However, I don't think > > > it would be difficult to accommodate this within ffado. There may be a need > > > to include a configuration entry with the "boot loader" model ID > > > (0x00010070) in addition to the main one. Then if the FW1814 probe/discover > > > methods detected this they could arrange to send the special command at that > > > point. After delaying for a suitable time it could then retry the probe to > > > find the initialised FW-1814. It may even be possible to have the > > > initialisation command in the probe() method so that by the time discover() > > > is called the interface is ready to go. > > I like the idea about additional parameter. I think it is easier and > > more reliable to handle 'bus reset' than sleep() for some time. 'bus > > reset' will be generated because the topology is changed. There is a > > function virtual bool FFADODevice::needsRediscovery(); which may be > > used I think to infrom that rediscovery is required after bus reset. > > The boot loader trigger could be a small stand-alone utility plus an udev > rule which invokes this utility when the boot loader vendor:model IDs shows > up in an 'add' uevent. I like this suggested udev solution. It's relatively neat and wouldn't take a lot of effort to implement. This way ffado would only need to know and care about the "initialised" model ID, and it immediately resolves the need for ffado do deal with bus resets in the middle of the probe/discovery sequence. FFADO already ships udev rules, so it wouldn't be hard to integrate another one to handle the initialisation of these devices. > Alternatively, this could be implemented as a tiny kernel module. This > doesn't make much sense at this point in time, but could make some sense if > a BeBoB ALSA streaming driver (with M-Audio stream format support) is > being added to the kernel too. Ultimately the plan is to move all the streaming code into the kernel. However, to get something going quickly the udev approach appears to be an efficient way to go, and it's not conceptually messy. jonathan |
From: Takashi S. <o-t...@sa...> - 2013-06-21 15:02:38
|
Hi Stefan, > Alternatively, this could be implemented as a tiny kernel module. > This doesn't make much sense at this point in time, but could make > some sense if a BeBoB ALSA streaming driver (with M-Audio stream > format support) is being added to the kernel too. When I test the magic bytes during probing process of my snd-bebob (under heavily development), it's always timeout. I don't know where the cause is, in device side or juju side. Anyway for this issue, I'll post to linux1394-devel later, maybe when I finish to implement full-duplex synchronization of amdtp streams in snd-firewire-lib. Thanks Takashi Sakamoto o-t...@sa... (Jun 21 2013 23:45), Stefan Richter wrote: > On Jun 21 Michael Malyshev wrote: >>>> The catch is the device starts in 'bootloader' mode after power-on-reset >>>> and has to be switched to 'FW 1814' mode by special command which I can >>>> send manually using is using simple utility 'fireconntrol' with my >>>> modifications to send variable length block >>> Right. That is different to most other interfaces. However, I don't think >>> it would be difficult to accommodate this within ffado. There may be a need >>> to include a configuration entry with the "boot loader" model ID >>> (0x00010070) in addition to the main one. Then if the FW1814 probe/discover >>> methods detected this they could arrange to send the special command at that >>> point. After delaying for a suitable time it could then retry the probe to >>> find the initialised FW-1814. It may even be possible to have the >>> initialisation command in the probe() method so that by the time discover() >>> is called the interface is ready to go. >> I like the idea about additional parameter. I think it is easier and >> more reliable to handle 'bus reset' than sleep() for some time. 'bus >> reset' will be generated because the topology is changed. There is a >> function virtual bool FFADODevice::needsRediscovery(); which may be >> used I think to infrom that rediscovery is required after bus reset. > > The boot loader trigger could be a small stand-alone utility plus an udev > rule which invokes this utility when the boot loader vendor:model IDs shows > up in an 'add' uevent. > > Alternatively, this could be implemented as a tiny kernel module. This > doesn't make much sense at this point in time, but could make some sense if > a BeBoB ALSA streaming driver (with M-Audio stream format support) is > being added to the kernel too. |
From: Michael M. <mih...@ya...> - 2013-06-21 16:49:39
|
On 06/21/2013 07:02 PM, Takashi Sakamoto wrote: > Hi Stefan, > > > Alternatively, this could be implemented as a tiny kernel module. > > This doesn't make much sense at this point in time, but could make > > some sense if a BeBoB ALSA streaming driver (with M-Audio stream > > format support) is being added to the kernel too. > > When I test the magic bytes during probing process of my snd-bebob > (under heavily development), it's always timeout. I don't know where the > cause is, in device side or juju side. Hi Takashi, I'm sure you know it, but in case you always keep your HW powered because of continious development: the magic sequence has to be send only once after device powered up. Any manipulations with device do not put it back to bootloader mode until the next power down. Regards, --Michael > Anyway for this issue, I'll post to linux1394-devel later, maybe when I > finish to implement full-duplex synchronization of amdtp streams in > snd-firewire-lib. > > Thanks > > > Takashi Sakamoto > o-t...@sa... > > > (Jun 21 2013 23:45), Stefan Richter wrote: >> On Jun 21 Michael Malyshev wrote: >>>>> The catch is the device starts in 'bootloader' mode after power-on-reset >>>>> and has to be switched to 'FW 1814' mode by special command which I can >>>>> send manually using is using simple utility 'fireconntrol' with my >>>>> modifications to send variable length block >>>> Right. That is different to most other interfaces. However, I don't think >>>> it would be difficult to accommodate this within ffado. There may be a need >>>> to include a configuration entry with the "boot loader" model ID >>>> (0x00010070) in addition to the main one. Then if the FW1814 probe/discover >>>> methods detected this they could arrange to send the special command at that >>>> point. After delaying for a suitable time it could then retry the probe to >>>> find the initialised FW-1814. It may even be possible to have the >>>> initialisation command in the probe() method so that by the time discover() >>>> is called the interface is ready to go. >>> I like the idea about additional parameter. I think it is easier and >>> more reliable to handle 'bus reset' than sleep() for some time. 'bus >>> reset' will be generated because the topology is changed. There is a >>> function virtual bool FFADODevice::needsRediscovery(); which may be >>> used I think to infrom that rediscovery is required after bus reset. >> The boot loader trigger could be a small stand-alone utility plus an udev >> rule which invokes this utility when the boot loader vendor:model IDs shows >> up in an 'add' uevent. >> >> Alternatively, this could be implemented as a tiny kernel module. This >> doesn't make much sense at this point in time, but could make some sense if >> a BeBoB ALSA streaming driver (with M-Audio stream format support) is >> being added to the kernel too. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Takashi S. <o-t...@sa...> - 2013-06-21 15:14:02
|
Hi Jonathan, > Ultimately the plan is to move all the streaming code into the kernel. > However, to get something going quickly the udev approach appears to > be an efficient way to go, and it's not conceptually messy. The udev idea is good. But I inform to you that: 1. There are some versions of driver for M-Audio's BeBoB devices. 2. In all drivers, the magic bytes look taking the bootloader to load firmware. 3. When I checked driver version 5034/5036/5058, both of 5034/5036 need to send firmware blob before sending the magic bytes. 4. So the solution should be applied for 5058. It's a bit complicated. I'm sorry but I have little time to do this commitment. I also created implementation chart of mixer commands for M-Audio (410/1814/Solo/Audiophile) and Yamaha (Go44/Go46) BeBoB based devices but do not keep enough time, too... Regards Takashi Sakamoto o-t...@sa... (Jun 21 2013 23:52), Jonathan Woithe wrote: > On Fri, Jun 21, 2013 at 04:45:52PM +0200, Stefan Richter wrote: >> On Jun 21 Michael Malyshev wrote: >>>>> The catch is the device starts in 'bootloader' mode after power-on-reset >>>>> and has to be switched to 'FW 1814' mode by special command which I can >>>>> send manually using is using simple utility 'fireconntrol' with my >>>>> modifications to send variable length block >>>> Right. That is different to most other interfaces. However, I don't think >>>> it would be difficult to accommodate this within ffado. There may be a need >>>> to include a configuration entry with the "boot loader" model ID >>>> (0x00010070) in addition to the main one. Then if the FW1814 probe/discover >>>> methods detected this they could arrange to send the special command at that >>>> point. After delaying for a suitable time it could then retry the probe to >>>> find the initialised FW-1814. It may even be possible to have the >>>> initialisation command in the probe() method so that by the time discover() >>>> is called the interface is ready to go. >>> I like the idea about additional parameter. I think it is easier and >>> more reliable to handle 'bus reset' than sleep() for some time. 'bus >>> reset' will be generated because the topology is changed. There is a >>> function virtual bool FFADODevice::needsRediscovery(); which may be >>> used I think to infrom that rediscovery is required after bus reset. >> >> The boot loader trigger could be a small stand-alone utility plus an udev >> rule which invokes this utility when the boot loader vendor:model IDs shows >> up in an 'add' uevent. > > I like this suggested udev solution. It's relatively neat and wouldn't take > a lot of effort to implement. This way ffado would only need to know and > care about the "initialised" model ID, and it immediately resolves the need > for ffado do deal with bus resets in the middle of the probe/discovery > sequence. > > FFADO already ships udev rules, so it wouldn't be hard to integrate another > one to handle the initialisation of these devices. > >> Alternatively, this could be implemented as a tiny kernel module. This >> doesn't make much sense at this point in time, but could make some sense if >> a BeBoB ALSA streaming driver (with M-Audio stream format support) is >> being added to the kernel too. > > Ultimately the plan is to move all the streaming code into the kernel. > However, to get something going quickly the udev approach appears to be an > efficient way to go, and it's not conceptually messy. > > jonathan |
From: Michael M. <mih...@ya...> - 2013-06-21 16:46:04
|
On 06/21/2013 07:13 PM, Takashi Sakamoto wrote: > Hi Jonathan, > > > Ultimately the plan is to move all the streaming code into the kernel. > > However, to get something going quickly the udev approach appears to > > be an efficient way to go, and it's not conceptually messy. > > The udev idea is good. But I inform to you that: > 1. There are some versions of driver for M-Audio's BeBoB devices. > 2. In all drivers, the magic bytes look taking the bootloader to load > firmware. > 3. When I checked driver version 5034/5036/5058, both of 5034/5036 need > to send firmware blob before sending the magic bytes. > 4. So the solution should be applied for 5058. > > It's a bit complicated. > > I'm sorry but I have little time to do this commitment. I also created > implementation chart of mixer commands for M-Audio > (410/1814/Solo/Audiophile) and Yamaha (Go44/Go46) BeBoB based devices > but do not keep enough time, too... Every time you install the latest version of drivers the new firmware( if available) is beeing flashed to the device. I think the driver sends firmware because the firmware flashed into device doesn't meet drivers expectation (it is newer). If you have firewire traffic log for the case driver sends firmware it would be great to have it, if no, I'll try to capture it. I could implement firmware uploading it in the same udev-utility. We'll always upload the latest firmware version if it is not flashed into the device. Later this code can be partially reused for the kernel driver's request_firmware() handling. --Michael > > > Regards > > Takashi Sakamoto > o-t...@sa... > > (Jun 21 2013 23:52), Jonathan Woithe wrote: >> On Fri, Jun 21, 2013 at 04:45:52PM +0200, Stefan Richter wrote: >>> On Jun 21 Michael Malyshev wrote: >>>>>> The catch is the device starts in 'bootloader' mode after power-on-reset >>>>>> and has to be switched to 'FW 1814' mode by special command which I can >>>>>> send manually using is using simple utility 'fireconntrol' with my >>>>>> modifications to send variable length block >>>>> Right. That is different to most other interfaces. However, I don't think >>>>> it would be difficult to accommodate this within ffado. There may be a need >>>>> to include a configuration entry with the "boot loader" model ID >>>>> (0x00010070) in addition to the main one. Then if the FW1814 probe/discover >>>>> methods detected this they could arrange to send the special command at that >>>>> point. After delaying for a suitable time it could then retry the probe to >>>>> find the initialised FW-1814. It may even be possible to have the >>>>> initialisation command in the probe() method so that by the time discover() >>>>> is called the interface is ready to go. >>>> I like the idea about additional parameter. I think it is easier and >>>> more reliable to handle 'bus reset' than sleep() for some time. 'bus >>>> reset' will be generated because the topology is changed. There is a >>>> function virtual bool FFADODevice::needsRediscovery(); which may be >>>> used I think to infrom that rediscovery is required after bus reset. >>> The boot loader trigger could be a small stand-alone utility plus an udev >>> rule which invokes this utility when the boot loader vendor:model IDs shows >>> up in an 'add' uevent. >> I like this suggested udev solution. It's relatively neat and wouldn't take >> a lot of effort to implement. This way ffado would only need to know and >> care about the "initialised" model ID, and it immediately resolves the need >> for ffado do deal with bus resets in the middle of the probe/discovery >> sequence. >> >> FFADO already ships udev rules, so it wouldn't be hard to integrate another >> one to handle the initialisation of these devices. >> >>> Alternatively, this could be implemented as a tiny kernel module. This >>> doesn't make much sense at this point in time, but could make some sense if >>> a BeBoB ALSA streaming driver (with M-Audio stream format support) is >>> being added to the kernel too. >> Ultimately the plan is to move all the streaming code into the kernel. >> However, to get something going quickly the udev approach appears to be an >> efficient way to go, and it's not conceptually messy. >> >> jonathan > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > FFADO-devel mailing list > FFA...@li... > https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Takashi S. <o-t...@sa...> - 2013-06-23 01:31:09
|
Hi Micheal > I think the driver sends firmware because the firmware flashed into > device doesn't meet drivers expectation (it is newer). If you have > firewire traffic log for the case driver sends firmware it would be > great to have it, if no, I'll try to capture it. I could implement > firmware uploading it in the same udev-utility. I have such a dump for FW410. FW410: (110MB) http://ubuntuone.com/1qfVxqI7fKT8YNJlRgrObo > We'll always upload the latest firmware version if it is not flashed > into the device. Later this code can be partially reused for the > kernel driver's request_firmware() handling. I agree with it. Regards Takashi Sakamoto o-t...@sa... (Jun 22 2013 01:45), Michael Malyshev wrote: > On 06/21/2013 07:13 PM, Takashi Sakamoto wrote: >> Hi Jonathan, >> >> > Ultimately the plan is to move all the streaming code into the >> kernel. >> > However, to get something going quickly the udev approach appears to >> > be an efficient way to go, and it's not conceptually messy. >> >> The udev idea is good. But I inform to you that: >> 1. There are some versions of driver for M-Audio's BeBoB devices. >> 2. In all drivers, the magic bytes look taking the bootloader to load >> firmware. >> 3. When I checked driver version 5034/5036/5058, both of 5034/5036 need >> to send firmware blob before sending the magic bytes. >> 4. So the solution should be applied for 5058. >> >> It's a bit complicated. >> >> I'm sorry but I have little time to do this commitment. I also created >> implementation chart of mixer commands for M-Audio >> (410/1814/Solo/Audiophile) and Yamaha (Go44/Go46) BeBoB based devices >> but do not keep enough time, too... > Every time you install the latest version of drivers the new firmware( > if available) is beeing flashed to the device. > > I think the driver sends firmware because the firmware flashed into > device doesn't meet drivers expectation (it is newer). If you have > firewire traffic log for the case driver sends firmware it would be > great to have it, if no, I'll try to capture it. I could implement > firmware uploading it in the same udev-utility. > > We'll always upload the latest firmware version if it is not flashed > into the device. Later this code can be partially reused for the kernel > driver's request_firmware() handling. > > --Michael |