Re: [alsa-devel] [FFADO-user] Toneweal / Trigaudio FW66 device
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
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
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
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
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
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
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/1c9fabb7dd9de36ea829... [3] https://github.com/takaswie/snd-firewire-improve/tree/topic/fw66
Regards
Takashi Sakamoto
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/1c9fabb7dd9de36ea829... [3] https://github.com/takaswie/snd-firewire-improve/tree/topic/fw66
Regards
Takashi Sakamoto
participants (2)
-
Daniel Jozsef -
Takashi Sakamoto