* Re: [alsa-devel] [FFADO-user] Toneweal / Trigaudio FW66 device [not found] ` <CAK5Eu=ucuW6Pp=+j7afPoYgPUdFXjh+PZ-PK6mc+m61M80ZndA@mail.gmail.com> @ 2020-01-19 16:43 ` Takashi Sakamoto 2020-01-20 11:42 ` Daniel Jozsef 0 siblings, 1 reply; 8+ messages in thread From: Takashi Sakamoto @ 2020-01-19 16:43 UTC (permalink / raw) To: Daniel Jozsef; +Cc: alsa-devel, ffado-user Hi, I'm an author of ALSA bebob driver (snd-bebob). On Sun, Jan 19, 2020 at 03:01:00PM +0100, Daniel Jozsef wrote: > It's a Toneweal FW66, a 6x6 in/out 24bit 96kHz audio interface with MIDI. I > kinda like it for its build quality and the time I spent with it. :D The > largest chip in the device is labeled Trigaudio MNP-TA110. I searched for > information on this device, and found very little - it's a Taiwanese > company. There seems evidence that a "Trigaudio FW66" also exists, so the > device may have been sold under different brands in different markets. In my opinion, FW66 is an application of ArchWave BeBoB solution for audio and music units on IEEE 1394 bus (ArchWave is formerly known as BridgeCo) since I can find file structure for the solution in driver package shipped by the vendor. I guess that you can see large ASIC labelled with 'BridgeCo' (or 'ArchWave') DM1000/1100/1500 inner the device. If so, the device is possibly handled by implementation of FFADO. But as a quick glance to your log, the implementation of FFADO fails to detect it: > daniel@gibbonmoon:~$ sudo ffado-test Discover > ... > 02878614308: Warning (bebob_avdevice.cpp)[ 228] discover: Using generic BeBoB support for unsupported device 'ToneWeal FW66' > 02878620133: Debug (bebob_avdevice_subunit.cpp)[ 83] discover: Discovering BeBoB::AudioSubunit... > 02878620175: Debug (avc_audiosubunit.cpp)[ 56] discover: Discovering BeBoB::AudioSubunit... > 02878620196: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering plugs... > 02878778208: Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement extended plug info plug type info command > 02878778236: Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover plug type (1,1,0,0,1) > 02878778272: Error (avc_subunit.cpp)[ 189] discoverPlugs: plug discover failed > 02878778283: Error (avc_subunit.cpp)[ 131] discoverPlugs: destination plug discovering failed > 02878778301: Error (avc_subunit.cpp)[ 99] discover: plug discovery failed > 02878778312: Error (avc_unit.cpp)[ 283] enumerateSubUnits: enumerateSubUnits: Could not discover subunit_id = 0, subunit_type = 1 (Audio) > 02878778335: Error (avc_unit.cpp)[ 177] discover: Could not enumerate sub units > 02878778347: Error (bebob_avdevice.cpp)[ 232] discover: Could not discover unit > 02878778376: Error (devicemanager.cpp)[ 628] discover: could not discover device > 02878778419: Debug (devicemanager.cpp)[ 661] discover: Discovery finished... ... The reason is the unit returns NOT_IMPLEMENTED response against vendor specific AV/C command (Extended Plug Information command defined by BridgeCo.) for Audio subunit. I guess that the device has no Audio subunit but the implementation performs to use it without checking available subunits. For my information, would you please clone linux-firewire-utils[1] into your system and build it, then run below command to dump device information: $ ./firewire-request /dev/fw1 read 0xffffc8020000 60 result: 000: 62 72 69 64 67 65 43 6f 03 00 00 00 00 00 00 00 bridgeCo........ result: 010: 00 96 14 00 22 03 00 00 19 00 00 00 00 00 00 00 ...."........... result: 020: 32 30 30 39 30 36 30 39 31 36 32 39 34 30 20 20 20090609162940 result: 030: 00 00 00 19 07 1f 00 00 80 00 0c 40 70 35 14 00 ...........@p5.. result: 040: 32 30 30 39 30 36 30 39 31 36 32 32 31 39 20 20 20090609162219 result: 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ The above is a sample of Phonic Firefly 202. I expect the first line includes bytes represent 'bridgeCo'. [1] https://github.com/cladisch/linux-firewire-utils Regards Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] [FFADO-user] Toneweal / Trigaudio FW66 device 2020-01-19 16:43 ` [alsa-devel] [FFADO-user] Toneweal / Trigaudio FW66 device Takashi Sakamoto @ 2020-01-20 11:42 ` Daniel Jozsef 2020-01-20 14:19 ` [alsa-devel] " Takashi Sakamoto 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jozsef @ 2020-01-20 11:42 UTC (permalink / raw) To: ffado-user, alsa-devel Hello, Thanks for the quick reaction, Takashi :) I ran the command you mentioned, and your guess was spot on: daniel@gibbonmoon:~/opt/linux-firewire-utils-0.4/src$ ./firewire-request /dev/fw1 read 0xffffc8020000 60 result: 000: 62 72 69 64 67 65 43 6f 03 00 00 00 00 00 00 00 bridgeCo........ result: 010: 00 27 23 00 00 00 00 02 02 00 00 00 00 00 00 00 .'#............. result: 020: 32 30 31 30 30 35 32 35 31 32 31 35 30 34 20 20 20100525121504 result: 030: 02 00 02 00 ff ff ff 00 80 00 0c 40 7c e3 13 00 ...........@|... result: 040: 32 30 30 38 31 32 30 32 31 33 34 34 34 38 20 20 20081202134448 result: 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Daniel On Sun, Jan 19, 2020 at 4:43 PM Takashi Sakamoto <o-takashi@sakamocchi.jp> wrote: > Hi, > > I'm an author of ALSA bebob driver (snd-bebob). > > On Sun, Jan 19, 2020 at 03:01:00PM +0100, Daniel Jozsef wrote: > > It's a Toneweal FW66, a 6x6 in/out 24bit 96kHz audio interface with > MIDI. I > > kinda like it for its build quality and the time I spent with it. :D The > > largest chip in the device is labeled Trigaudio MNP-TA110. I searched for > > information on this device, and found very little - it's a Taiwanese > > company. There seems evidence that a "Trigaudio FW66" also exists, so the > > device may have been sold under different brands in different markets. > > In my opinion, FW66 is an application of ArchWave BeBoB solution for > audio and music units on IEEE 1394 bus (ArchWave is formerly known as > BridgeCo) since I can find file structure for the solution in driver > package shipped by the vendor. I guess that you can see large ASIC > labelled with 'BridgeCo' (or 'ArchWave') DM1000/1100/1500 inner the > device. If so, the device is possibly handled by implementation of FFADO. > > But as a quick glance to your log, the implementation of FFADO fails to > detect it: > > > daniel@gibbonmoon:~$ sudo ffado-test Discover > > ... > > 02878614308: Warning (bebob_avdevice.cpp)[ 228] discover: Using generic > BeBoB support for unsupported device 'ToneWeal FW66' > > 02878620133: Debug (bebob_avdevice_subunit.cpp)[ 83] discover: > Discovering BeBoB::AudioSubunit... > > 02878620175: Debug (avc_audiosubunit.cpp)[ 56] discover: Discovering > BeBoB::AudioSubunit... > > 02878620196: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering > plugs... > > 02878778208: Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does > not implement extended plug info plug type info command > > 02878778236: Error (bebob_avplug.cpp)[ 120] discover: discover: Could > not discover plug type (1,1,0,0,1) > > 02878778272: Error (avc_subunit.cpp)[ 189] discoverPlugs: plug discover > failed > > 02878778283: Error (avc_subunit.cpp)[ 131] discoverPlugs: destination > plug discovering failed > > 02878778301: Error (avc_subunit.cpp)[ 99] discover: plug discovery > failed > > 02878778312: Error (avc_unit.cpp)[ 283] enumerateSubUnits: > enumerateSubUnits: Could not discover subunit_id = 0, subunit_type = 1 > (Audio) > > 02878778335: Error (avc_unit.cpp)[ 177] discover: Could not enumerate > sub units > > 02878778347: Error (bebob_avdevice.cpp)[ 232] discover: Could not > discover unit > > 02878778376: Error (devicemanager.cpp)[ 628] discover: could not > discover device > > 02878778419: Debug (devicemanager.cpp)[ 661] discover: Discovery > finished... > ... > > The reason is the unit returns NOT_IMPLEMENTED response against vendor > specific AV/C command (Extended Plug Information command defined by > BridgeCo.) for Audio subunit. I guess that the device has no Audio > subunit but the implementation performs to use it without checking > available subunits. > > > For my information, would you please clone linux-firewire-utils[1] into > your system and build it, then run below command to dump device > information: > > $ ./firewire-request /dev/fw1 read 0xffffc8020000 60 > result: 000: 62 72 69 64 67 65 43 6f 03 00 00 00 00 00 00 00 > bridgeCo........ > result: 010: 00 96 14 00 22 03 00 00 19 00 00 00 00 00 00 00 > ...."........... > result: 020: 32 30 30 39 30 36 30 39 31 36 32 39 34 30 20 20 20090609162940 > result: 030: 00 00 00 19 07 1f 00 00 80 00 0c 40 70 35 14 00 > ...........@p5.. > result: 040: 32 30 30 39 30 36 30 39 31 36 32 32 31 39 20 20 20090609162219 > result: 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ > > The above is a sample of Phonic Firefly 202. I expect the first line > includes bytes represent 'bridgeCo'. > > [1] https://github.com/cladisch/linux-firewire-utils > > > Regards > > Takashi Sakamoto > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-20 11:42 ` Daniel Jozsef @ 2020-01-20 14:19 ` Takashi Sakamoto 2020-01-24 22:16 ` Daniel Jozsef 0 siblings, 1 reply; 8+ messages in thread From: Takashi Sakamoto @ 2020-01-20 14:19 UTC (permalink / raw) To: Daniel Jozsef; +Cc: alsa-devel, ffado-user Hi Daniel, On Mon, Jan 20, 2020 at 11:42:34AM +0000, Daniel Jozsef wrote: > Thanks for the quick reaction, Takashi :) I ran the command you mentioned, > and your guess was spot on: > > daniel@gibbonmoon:~/opt/linux-firewire-utils-0.4/src$ ./firewire-request > /dev/fw1 read 0xffffc8020000 60 > result: 000: 62 72 69 64 67 65 43 6f 03 00 00 00 00 00 00 00 bridgeCo........ > result: 010: 00 27 23 00 00 00 00 02 02 00 00 00 00 00 00 00 .'#............. > result: 020: 32 30 31 30 30 35 32 35 31 32 31 35 30 34 20 20 20100525121504 > result: 030: 02 00 02 00 ff ff ff 00 80 00 0c 40 7c e3 13 00 ...........@|... > result: 040: 32 30 30 38 31 32 30 32 31 33 34 34 34 38 20 20 20081202134448 > result: 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Yep, it's an application of BeBoB solution. As a next step, please get responses against 5 AV/C commands below: (AV/C UNIT INFO command) $ ./firewire-request /dev/fw1 fcp 0x01ff3000ffffffff response: 000: 0c ff 30 07 0f 00 14 96 ..0..... (AV/C SUBUNIT INFO command) $ ./firewire-request /dev/fw1 fcp 0x01ff3100ffffffff response: 000: 0c ff 31 00 08 60 ff ff ..1..`.. (AV/C PLUG INFO command for Unit) $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff response: 000: 0c ff 02 00 02 02 01 01 ........ (AV/C PLUG INFO command for Audio subunit) $ ./firewire-request /dev/fw1 fcp 0x01080200ffffffff response: 000: 0c 08 02 00 02 02 ff ff ........ (AV/C PLUG INFO command for Music subunit) $ ./firewire-request /dev/fw1 fcp 0x01600200ffffffff response: 000: 0c 60 02 00 03 03 ff ff .`...... If you're interested in their contents, please refer to document published by 1394 Trading Association: AV/C Digital Interface Command Set General Specification Version 4.2 (1394 Trading Association, September 1, 2004) http://1394ta.org/wp-content/uploads/2015/07/2004006.pdf Thanks Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-20 14:19 ` [alsa-devel] " Takashi Sakamoto @ 2020-01-24 22:16 ` Daniel Jozsef 2020-01-25 3:18 ` Takashi Sakamoto 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jozsef @ 2020-01-24 22:16 UTC (permalink / raw) To: Daniel Jozsef, ffado-user, alsa-devel Hello Takashi, Thanks for getting involved, I really appreciate it! :D I was away this week, but today I was able to run the commands you mentioned. $ ./firewire-request /dev/fw1 fcp 0x01ff3000ffffffff response: 000: 0c ff 30 07 0f 00 23 27 ..0...#' $ ./firewire-request /dev/fw1 fcp 0x01ff3100ffffffff response: 000: 0c ff 31 00 08 60 ff ff ..1..`.. $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff response: 000: 0c ff 02 00 02 02 04 03 ........ $ ./firewire-request /dev/fw1 fcp 0x01080200ffffffff response: 000: 0c 08 02 00 04 01 ff ff ........ $ ./firewire-request /dev/fw1 fcp 0x01600200ffffffff response: 000: 0c 60 02 00 06 05 ff ff .`...... From what I gather from the reference you linked, this seems more or less what's expected, though I'm not entirely sure yet what it means for the device to have 6 destination and 5 source plugs on the music subunit... :D (If I read the specs correctly...) Daniel On Mon, Jan 20, 2020 at 2:19 PM Takashi Sakamoto <o-takashi@sakamocchi.jp> wrote: > Hi Daniel, > > On Mon, Jan 20, 2020 at 11:42:34AM +0000, Daniel Jozsef wrote: > > Thanks for the quick reaction, Takashi :) I ran the command you > mentioned, > > and your guess was spot on: > > > > daniel@gibbonmoon:~/opt/linux-firewire-utils-0.4/src$ ./firewire-request > > /dev/fw1 read 0xffffc8020000 60 > > result: 000: 62 72 69 64 67 65 43 6f 03 00 00 00 00 00 00 00 > bridgeCo........ > > result: 010: 00 27 23 00 00 00 00 02 02 00 00 00 00 00 00 00 > .'#............. > > result: 020: 32 30 31 30 30 35 32 35 31 32 31 35 30 34 20 20 > 20100525121504 > > result: 030: 02 00 02 00 ff ff ff 00 80 00 0c 40 7c e3 13 00 > ...........@|... > > result: 040: 32 30 30 38 31 32 30 32 31 33 34 34 34 38 20 20 > 20081202134448 > > result: 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ................ > > Yep, it's an application of BeBoB solution. > > As a next step, please get responses against 5 AV/C commands below: > > (AV/C UNIT INFO command) > $ ./firewire-request /dev/fw1 fcp 0x01ff3000ffffffff > response: 000: 0c ff 30 07 0f 00 14 96 ..0..... > > (AV/C SUBUNIT INFO command) > $ ./firewire-request /dev/fw1 fcp 0x01ff3100ffffffff > response: 000: 0c ff 31 00 08 60 ff ff ..1..`.. > > (AV/C PLUG INFO command for Unit) > $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff > response: 000: 0c ff 02 00 02 02 01 01 ........ > > (AV/C PLUG INFO command for Audio subunit) > $ ./firewire-request /dev/fw1 fcp 0x01080200ffffffff > response: 000: 0c 08 02 00 02 02 ff ff ........ > > (AV/C PLUG INFO command for Music subunit) > $ ./firewire-request /dev/fw1 fcp 0x01600200ffffffff > response: 000: 0c 60 02 00 03 03 ff ff .`...... > > If you're interested in their contents, please refer to document published > by > 1394 Trading Association: > > AV/C Digital Interface Command Set General Specification Version 4.2 > (1394 Trading Association, September 1, 2004) > http://1394ta.org/wp-content/uploads/2015/07/2004006.pdf > > > Thanks > > Takashi Sakamoto > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-24 22:16 ` Daniel Jozsef @ 2020-01-25 3:18 ` Takashi Sakamoto 2020-01-28 22:28 ` Daniel Jozsef 0 siblings, 1 reply; 8+ messages in thread From: Takashi Sakamoto @ 2020-01-25 3:18 UTC (permalink / raw) To: Daniel Jozsef; +Cc: alsa-devel, ffado-user Hi, On Fri, Jan 24, 2020 at 10:16:53PM +0000, Daniel Jozsef wrote: > $ ./firewire-request /dev/fw1 fcp 0x01ff3000ffffffff > response: 000: 0c ff 30 07 0f 00 23 27 ..0...#' > $ ./firewire-request /dev/fw1 fcp 0x01ff3100ffffffff > response: 000: 0c ff 31 00 08 60 ff ff ..1..`.. > $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff > response: 000: 0c ff 02 00 02 02 04 03 ........ > $ ./firewire-request /dev/fw1 fcp 0x01080200ffffffff > response: 000: 0c 08 02 00 04 01 ff ff ........ > $ ./firewire-request /dev/fw1 fcp 0x01600200ffffffff > response: 000: 0c 60 02 00 06 05 ff ff .`...... > > From what I gather from the reference you linked, this seems more or less > what's expected, though I'm not entirely sure yet what it means for the > device to have 6 destination and 5 source plugs on the music subunit... :D > (If I read the specs correctly...) You got it correctly. Here, let's back to FFADO log: > Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement extended plug info plug type info command > Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover plug type (1,1,0,0,1) > Error (avc_subunit.cpp)[ 189] discoverPlugs: plug discover failed > Error (avc_subunit.cpp)[ 131] discoverPlugs: destination plug discovering failed > Error (avc_subunit.cpp)[ 99] discover: plug discovery failed > Error (avc_unit.cpp)[ 283] enumerateSubUnits: enumerateSubUnits: Could not discover subunit_id = 0, subunit_type = 1 (Audio) > Error (avc_unit.cpp)[ 177] discover: Could not enumerate sub units It's my mistake to interpret the target subunit to which the command fails. It's 'Audio' subunit, not 'Music' subunit... > plug type (1,1,0,0,1) 1 = node ID (=0xFF01) 1 = subunit type (=audio) 0 = subunit ID 0 = direction (=input) 1 = plug ID (=0x01) The EXTENDED PLUG INFO command is one of specific command for BeBoB solution and its specification is closed. In your case, 4 plugs are detected as destination plug and 1 plug as source plug in Audio subunit by AV/C PLUG INFO command for Audio subunit, thus below commands are expected to return valid information as long as implemented correctly: (4 destination plugs = 4 input plugs) (AV/C EXTENDED PLUG INFO command for input plugs of Music subunit) $ ./firewire-request /dev/fw1 fcp 0x016002c0000100ffff00 $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 (<-) $ ./firewire-request /dev/fw1 fcp 0x016002c0000102ffff00 $ ./firewire-request /dev/fw1 fcp 0x016002c0000103ffff00 $ ./firewire-request /dev/fw1 fcp 0x016002c0000104ffff00 (should fail) (1 source plug = 1 output plug) (AV/C EXTENDED PLUG INFO command for output plugs of Music subunit) $ ./firewire-request /dev/fw1 fcp 0x016002c0010100ffff00 $ ./firewire-request /dev/fw1 fcp 0x016002c0010101ffff00 (should fail) However, some vendors seem to implement the above with less care of compatibility, as long as I know. In your case, below command might fail: $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 (<-) I'd like you to execute the above commands and share their responses. Regards Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-25 3:18 ` Takashi Sakamoto @ 2020-01-28 22:28 ` Daniel Jozsef 2020-01-29 3:16 ` Takashi Sakamoto 0 siblings, 1 reply; 8+ messages in thread From: Daniel Jozsef @ 2020-01-28 22:28 UTC (permalink / raw) To: Daniel Jozsef, ffado-user, alsa-devel Hey Takashi, I'm a little baffled by what my device just did. :P $ ./firewire-request /dev/fw1 fcp 0x016002c0000100ffff00 response: 000: 0c 60 02 c0 00 01 00 ff ff 00 00 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 response: 000: 0c 60 02 c0 00 01 01 ff ff 00 00 .`......... (<- didn't fail) $ ./firewire-request /dev/fw1 fcp 0x016002c0000102ffff00 response: 000: 0c 60 02 c0 00 01 02 ff ff 00 00 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0000103ffff00 response: 000: 0c 60 02 c0 00 01 03 ff ff 00 00 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0000104ffff00 response: 000: 0c 60 02 c0 00 01 04 ff ff 00 02 .`......... (<- didn't fail) In fact... $ ./firewire-request /dev/fw1 fcp 0x016002c0000105ffff00 response: 000: 0c 60 02 c0 00 01 05 ff ff 00 03 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0000106ffff00 response: 000: 08 60 02 c0 00 01 06 ff ff 00 .`........ (<- shorter) $ ./firewire-request /dev/fw1 fcp 0x016002c0000107ffff00 response: 000: 08 60 02 c0 00 01 07 ff ff 00 .`........ $ ./firewire-request /dev/fw1 fcp 0x016002c00001ffffff00 response: 000: 08 60 02 c0 00 01 ff ff ff 00 .`........ (<-srsly?) As for the second batch: $ ./firewire-request /dev/fw1 fcp 0x016002c0010100ffff00 response: 000: 0c 60 02 c0 01 01 00 ff ff 00 00 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0010101ffff00 response: 000: 0c 60 02 c0 01 01 01 ff ff 00 00 .`......... (<- didn't fail) So again... $ ./firewire-request /dev/fw1 fcp 0x016002c0010102ffff00 response: 000: 0c 60 02 c0 01 01 02 ff ff 00 00 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0010103ffff00 response: 000: 0c 60 02 c0 01 01 03 ff ff 00 02 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0010104ffff00 response: 000: 0c 60 02 c0 01 01 04 ff ff 00 03 .`......... $ ./firewire-request /dev/fw1 fcp 0x016002c0010105ffff00 response: 000: 08 60 02 c0 01 01 05 ff ff 00 .`........ (<- shorter) $ ./firewire-request /dev/fw1 fcp 0x016002c0010106ffff00 response: 000: 08 60 02 c0 01 01 06 ff ff 00 .`........ $ ./firewire-request /dev/fw1 fcp 0x016002c001010fffff00 response: 000: 08 60 02 c0 01 01 0f ff ff 00 .`........ Honestly I have no idea what is going on. :D Daniel On Sat, Jan 25, 2020 at 3:18 AM Takashi Sakamoto <o-takashi@sakamocchi.jp> wrote: > Hi, > > On Fri, Jan 24, 2020 at 10:16:53PM +0000, Daniel Jozsef wrote: > > $ ./firewire-request /dev/fw1 fcp 0x01ff3000ffffffff > > response: 000: 0c ff 30 07 0f 00 23 27 ..0...#' > > $ ./firewire-request /dev/fw1 fcp 0x01ff3100ffffffff > > response: 000: 0c ff 31 00 08 60 ff ff ..1..`.. > > $ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff > > response: 000: 0c ff 02 00 02 02 04 03 ........ > > $ ./firewire-request /dev/fw1 fcp 0x01080200ffffffff > > response: 000: 0c 08 02 00 04 01 ff ff ........ > > $ ./firewire-request /dev/fw1 fcp 0x01600200ffffffff > > response: 000: 0c 60 02 00 06 05 ff ff .`...... > > > > From what I gather from the reference you linked, this seems more or less > > what's expected, though I'm not entirely sure yet what it means for the > > device to have 6 destination and 5 source plugs on the music subunit... > :D > > (If I read the specs correctly...) > > You got it correctly. Here, let's back to FFADO log: > > > Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement > extended plug info plug type info command > > Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover > plug type (1,1,0,0,1) > > Error (avc_subunit.cpp)[ 189] discoverPlugs: plug discover failed > > Error (avc_subunit.cpp)[ 131] discoverPlugs: destination plug > discovering failed > > Error (avc_subunit.cpp)[ 99] discover: plug discovery failed > > Error (avc_unit.cpp)[ 283] enumerateSubUnits: enumerateSubUnits: Could > not discover subunit_id = 0, subunit_type = 1 (Audio) > > Error (avc_unit.cpp)[ 177] discover: Could not enumerate sub units > > It's my mistake to interpret the target subunit to which the command > fails. It's 'Audio' subunit, not 'Music' subunit... > > > plug type (1,1,0,0,1) > 1 = node ID (=0xFF01) > 1 = subunit type (=audio) > 0 = subunit ID > 0 = direction (=input) > 1 = plug ID (=0x01) > > The EXTENDED PLUG INFO command is one of specific command for BeBoB > solution and its specification is closed. In your case, 4 plugs are > detected as destination plug and 1 plug as source plug in Audio > subunit by AV/C PLUG INFO command for Audio subunit, thus below > commands are expected to return valid information as long as > implemented correctly: > > (4 destination plugs = 4 input plugs) > (AV/C EXTENDED PLUG INFO command for input plugs of Music subunit) > $ ./firewire-request /dev/fw1 fcp 0x016002c0000100ffff00 > $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 (<-) > $ ./firewire-request /dev/fw1 fcp 0x016002c0000102ffff00 > $ ./firewire-request /dev/fw1 fcp 0x016002c0000103ffff00 > $ ./firewire-request /dev/fw1 fcp 0x016002c0000104ffff00 (should fail) > > (1 source plug = 1 output plug) > (AV/C EXTENDED PLUG INFO command for output plugs of Music subunit) > $ ./firewire-request /dev/fw1 fcp 0x016002c0010100ffff00 > $ ./firewire-request /dev/fw1 fcp 0x016002c0010101ffff00 (should fail) > > However, some vendors seem to implement the above with less care of > compatibility, as long as I know. In your case, below command might > fail: > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 (<-) > > I'd like you to execute the above commands and share their responses. > > > Regards > > Takashi Sakamoto > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-28 22:28 ` Daniel Jozsef @ 2020-01-29 3:16 ` Takashi Sakamoto 2020-02-04 16:40 ` Daniel Jozsef 0 siblings, 1 reply; 8+ messages in thread From: Takashi Sakamoto @ 2020-01-29 3:16 UTC (permalink / raw) To: Daniel Jozsef; +Cc: alsa-devel, ffado-user Hi, On Tue, Jan 28, 2020 at 10:28:20PM +0000, Daniel Jozsef wrote: > I'm a little baffled by what my device just did. :P > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000100ffff00 > response: 000: 0c 60 02 c0 00 01 00 ff ff 00 00 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 > response: 000: 0c 60 02 c0 00 01 01 ff ff 00 00 .`......... > (<- didn't fail) > $ ./firewire-request /dev/fw1 fcp 0x016002c0000102ffff00 > response: 000: 0c 60 02 c0 00 01 02 ff ff 00 00 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0000103ffff00 > response: 000: 0c 60 02 c0 00 01 03 ff ff 00 00 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0000104ffff00 > response: 000: 0c 60 02 c0 00 01 04 ff ff 00 02 .`......... > (<- didn't fail) > > In fact... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000105ffff00 > response: 000: 0c 60 02 c0 00 01 05 ff ff 00 03 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0000106ffff00 > response: 000: 08 60 02 c0 00 01 06 ff ff 00 .`........ > (<- shorter) > $ ./firewire-request /dev/fw1 fcp 0x016002c0000107ffff00 > response: 000: 08 60 02 c0 00 01 07 ff ff 00 .`........ > $ ./firewire-request /dev/fw1 fcp 0x016002c00001ffffff00 > response: 000: 08 60 02 c0 00 01 ff ff ff 00 .`........ > (<-srsly?) > > As for the second batch: > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010100ffff00 > response: 000: 0c 60 02 c0 01 01 00 ff ff 00 00 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0010101ffff00 > response: 000: 0c 60 02 c0 01 01 01 ff ff 00 00 .`......... > (<- didn't fail) > > So again... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010102ffff00 > response: 000: 0c 60 02 c0 01 01 02 ff ff 00 00 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0010103ffff00 > response: 000: 0c 60 02 c0 01 01 03 ff ff 00 02 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0010104ffff00 > response: 000: 0c 60 02 c0 01 01 04 ff ff 00 03 .`......... > $ ./firewire-request /dev/fw1 fcp 0x016002c0010105ffff00 > response: 000: 08 60 02 c0 01 01 05 ff ff 00 .`........ > (<- shorter) > $ ./firewire-request /dev/fw1 fcp 0x016002c0010106ffff00 > response: 000: 08 60 02 c0 01 01 06 ff ff 00 .`........ > $ ./firewire-request /dev/fw1 fcp 0x016002c001010fffff00 > response: 000: 08 60 02 c0 01 01 0f ff ff 00 .`........ > > Honestly I have no idea what is going on. :D It looks to work well. You tried for input plugs of audio subunit, thus the shorter response with 0x08 in the first byte (=NOT IMPLEMENTED) is expected for inquiry to 6th input plug. Hm. I guess your issue is a kind of Heisenbugs[1]. It seems to depend on case. To drill down the case in which the issue appears, I'd like you to investigate whether you can see the same log every time you run with libffado (jackd with Firewire backend, or ffado-dbus-server) or not: > Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement extended plug info plug type info command > Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover plug type (1,1,0,0,1) Additionally, I write a patch for ALSA bebob driver to support your device[2]. If you need a prompt solution to use the device in Linux-based system, it's available in topic branch of my remote repository. But it's required for you to study the way to update installed driver modules... I note that ALSA bebob driver supports transmission of audio frames and MIDI messages, thus it's not available to control internal DSP. [1] https://en.wikipedia.org/wiki/Heisenbug [2] https://github.com/takaswie/snd-firewire-improve/commit/1c9fabb7dd9de36ea829700df7eb13a40393a679 [3] https://github.com/takaswie/snd-firewire-improve/tree/topic/fw66 Regards Takashi Sakamoto _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [alsa-devel] Toneweal / Trigaudio FW66 device 2020-01-29 3:16 ` Takashi Sakamoto @ 2020-02-04 16:40 ` Daniel Jozsef 0 siblings, 0 replies; 8+ messages in thread From: Daniel Jozsef @ 2020-02-04 16:40 UTC (permalink / raw) To: Daniel Jozsef, ffado-user, alsa-devel Hey, Thanks a lot. That does sound pretty strange. Thankfully, I'm in no hurry as I'm still mainly using an older Mac for audio stuff, but I'd like to replace it sooner or later, and getting an upgradable Linux machine sounds better than paying 1.5 to 2 times as much for a Mac with the same specs (and no extensibility). I'll try to do some testing around on my current Linux box. Unfortunately it's an old machine with a "known problematic" Firewire implementation, though I doubt that should play a part in device discovery. Daniel On Wed, Jan 29, 2020 at 4:16 AM Takashi Sakamoto <o-takashi@sakamocchi.jp> wrote: > Hi, > > On Tue, Jan 28, 2020 at 10:28:20PM +0000, Daniel Jozsef wrote: > > I'm a little baffled by what my device just did. :P > > > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000100ffff00 > > response: 000: 0c 60 02 c0 00 01 00 ff ff 00 00 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000101ffff00 > > response: 000: 0c 60 02 c0 00 01 01 ff ff 00 00 > .`......... > > (<- didn't fail) > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000102ffff00 > > response: 000: 0c 60 02 c0 00 01 02 ff ff 00 00 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000103ffff00 > > response: 000: 0c 60 02 c0 00 01 03 ff ff 00 00 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000104ffff00 > > response: 000: 0c 60 02 c0 00 01 04 ff ff 00 02 > .`......... > > (<- didn't fail) > > > > In fact... > > > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000105ffff00 > > response: 000: 0c 60 02 c0 00 01 05 ff ff 00 03 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000106ffff00 > > response: 000: 08 60 02 c0 00 01 06 ff ff 00 .`........ > > (<- shorter) > > $ ./firewire-request /dev/fw1 fcp 0x016002c0000107ffff00 > > response: 000: 08 60 02 c0 00 01 07 ff ff 00 .`........ > > $ ./firewire-request /dev/fw1 fcp 0x016002c00001ffffff00 > > response: 000: 08 60 02 c0 00 01 ff ff ff 00 .`........ > > (<-srsly?) > > > > As for the second batch: > > > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010100ffff00 > > response: 000: 0c 60 02 c0 01 01 00 ff ff 00 00 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010101ffff00 > > response: 000: 0c 60 02 c0 01 01 01 ff ff 00 00 > .`......... > > (<- didn't fail) > > > > So again... > > > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010102ffff00 > > response: 000: 0c 60 02 c0 01 01 02 ff ff 00 00 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010103ffff00 > > response: 000: 0c 60 02 c0 01 01 03 ff ff 00 02 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010104ffff00 > > response: 000: 0c 60 02 c0 01 01 04 ff ff 00 03 > .`......... > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010105ffff00 > > response: 000: 08 60 02 c0 01 01 05 ff ff 00 .`........ > > (<- shorter) > > $ ./firewire-request /dev/fw1 fcp 0x016002c0010106ffff00 > > response: 000: 08 60 02 c0 01 01 06 ff ff 00 .`........ > > $ ./firewire-request /dev/fw1 fcp 0x016002c001010fffff00 > > response: 000: 08 60 02 c0 01 01 0f ff ff 00 .`........ > > > > Honestly I have no idea what is going on. :D > > It looks to work well. > > You tried for input plugs of audio subunit, thus the shorter > response with 0x08 in the first byte (=NOT IMPLEMENTED) is > expected for inquiry to 6th input plug. > > Hm. I guess your issue is a kind of Heisenbugs[1]. It seems to > depend on case. To drill down the case in which the issue > appears, I'd like you to investigate whether you can see the > same log every time you run with libffado (jackd with Firewire > backend, or ffado-dbus-server) or not: > > > Error (bebob_avplug.cpp)[ 237] discoverPlugType: Plug does not implement > extended plug info plug type info command > > Error (bebob_avplug.cpp)[ 120] discover: discover: Could not discover > plug type (1,1,0,0,1) > > > Additionally, I write a patch for ALSA bebob driver to support > your device[2]. If you need a prompt solution to use the device in > Linux-based system, it's available in topic branch of my remote > repository. But it's required for you to study the way to update > installed driver modules... > > I note that ALSA bebob driver supports transmission of audio frames > and MIDI messages, thus it's not available to control internal DSP. > > [1] https://en.wikipedia.org/wiki/Heisenbug > [2] > https://github.com/takaswie/snd-firewire-improve/commit/1c9fabb7dd9de36ea829700df7eb13a40393a679 > [3] https://github.com/takaswie/snd-firewire-improve/tree/topic/fw66 > > > Regards > > Takashi Sakamoto > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-04 16:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAK5Eu=tVQjBn+YvsHOLqSEir5aV8Q0hA1OgFiJZYdqnspdMz-Q@mail.gmail.com> [not found] ` <CAK5Eu=snx3s9r9hoeF4Th0V0YXJYa=7PKUqDn3W4NdWZben-zg@mail.gmail.com> [not found] ` <CAK5Eu=v2x+zFhCygKq8DPWd+CH5JTpZEayg=k2NvaTY7DUNA9g@mail.gmail.com> [not found] ` <CAK5Eu=ucuW6Pp=+j7afPoYgPUdFXjh+PZ-PK6mc+m61M80ZndA@mail.gmail.com> 2020-01-19 16:43 ` [alsa-devel] [FFADO-user] Toneweal / Trigaudio FW66 device Takashi Sakamoto 2020-01-20 11:42 ` Daniel Jozsef 2020-01-20 14:19 ` [alsa-devel] " Takashi Sakamoto 2020-01-24 22:16 ` Daniel Jozsef 2020-01-25 3:18 ` Takashi Sakamoto 2020-01-28 22:28 ` Daniel Jozsef 2020-01-29 3:16 ` Takashi Sakamoto 2020-02-04 16:40 ` Daniel Jozsef
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).