All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.