Thread: Re: Question regarding linux1394 and bug report

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi,

On Fri, Jan 05, 2024 at 02:13:00PM +0200, Tasos Sahanidis wrote:
> Hi Takashi,
> 
> Thank you for your work in the Linux FireWire subsystem, and apologies
> for this direct email.
> 
> About a year ago I sent an email [0] to the linux1394 (user) mailing
> list with a bug report but received no response. I've been subscribed to
> linux1394-devel as well since and I've seen that it is now active.
> 
> I remember reading that there is a no cross-posting rule, thus I haven't
> re-sent my message to linux1394-devel. I have access to this hardware
> again, and will do for about the next two weeks.
> 
> Is this something you'd be interested in helping me with? If so, do you
> want me to re-send the e-mail to linux1394-devel and continue the
> conversation there? The issue still occurs on Ubuntu 22.04 with kernel
> 6.6.9.
> 
> Thank you for your time and looking forward to your response.
> 
> --
> Tasos
> 
> [0] https://sourceforge.net/p/linux1394/mailman/message/37766465/

I'm not good at any type of video protocol over IEEE 1394, thus less help
to your issue, sorry.

As a quick glance, you need to identify the direct cause of your issue
that dvgrab never receives video data at recent version of kernel at
first, then go to investigate kernel implementation if needed.

In my opinion, the best way is to investigate whether dvgrab (and
libavc1394) can operate your hardware to transfer isochronous packet
to your system.

For example, you have dumped the part of communication between dvgrab
and your hardware for AV/C commands. You can interpret them according to
specification specific to tape recorder and player protocol. You can see
two documents in 1394TA site archived by internet-archive project[1].

* AV/C Digital Interface Command Set General Specification Version 4.2
  (2004006)
* AV/C Tape Recorder/Player Subunit Specification 2.4 (2004005)

Below communication expresses:

```
 firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0120d07f
 firewire_ohci: AR spd 0 tl 2a, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0c20c460
 firewire_ohci: AT spd 0 tl 2a, ffc1 -> ffc0, ack_complete, W resp
```

[dvgrab -> hardware]
0x01: command type:    status
0x20: subunit type/id: tape recorder/player
0xd0: opcode:          transport state: 
0x7f: operand[0]:      0x7e

[hardware -> dvgrab]
0x0c: response: stable
0x20: subunit type/id: tape recorder/player
0xc4: opcode:          transport_mode:  wind
0x60: operand[0]:      transport_state: stop

Below communication expresses:

```
 firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, QW req, fffff0000b00 = 0020c375
 firewire_ohci: AR spd 0 tl 2d, ffc0 -> ffc1, ack_pending , QW req, fffff0000d00 = 0920c375
 firewire_ohci: AT spd 0 tl 2d, ffc1 -> ffc0, ack_complete, W resp
```

[dvgrab -> hardware]
0x00: command type:    control
0x20: subunit type/id: tape recorder/player
0xc3: opcode:          play
0x75: operand[0]:      playback_mode: forward

[hardware -> dvgrab]
0x09: response:        accepted
0x20: subunit type/id: tape recorder/player
0xc3: opcode:          play
0x75: operand[0]:      playback_mode: forward

I expect that if dvgrab takes the hardware to be prepared, it
keeps isochronous resources by operating both CHANNEL_AVAILABLE registers
(0xfffff0000224-0228) and BANDWIDTH_AVAILABLE register (0xfffff0000220),
and operate plug control registers (0xfffff0000900-0904) according to
IEC 61883-1. Then the hardware start transmission of isochronous
packets, defined in IEC 61883-1 and -2/-3/-5.

[1] https://web.archive.org/web/20200204014929/1394ta.org/specifications/

Regards

Takashi Sakamoto