CIP Discontinuity with snd-firewire-digi00x

CIP Discontinuity with snd-firewire-digi00x

[lin-alsa]

All,

I've been working to set up a Digi002 Rack mixer with Jack using the Alsa 
backend. Unfortunately, the mixer seems to desync or something after a few 
minutes - hours. dmesg gives me `snd-firewire-digi00x fw1.0: Detect 
discontinuity of CIP: XX XX` with XX XX replaced with various hex pairs. 
I'm not sure how to debug this, and any help would be much appreciated. 
Also, cat /proc/asound/card1/firewire/clock gives
`Optical mode: adat
Sampling Rate: 88200
Clock Source: internal` so I don't think it's an external clock issue.

Lin

Re: CIP Discontinuity with snd-firewire-digi00x

[Takashi Sakamoto]

Hi,

I've used the same unit for my development and test.

On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
> Unfortunately, the mixer seems to desync or something after a few
> minutes - hours. dmesg gives me `snd-firewire-digi00x fw1.0: Detect
> discontinuity of CIP: XX XX` with XX XX replaced with various hex
> pairs.

The hex pairs is important in this log, too.

On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
> so I don't think it's an external clock issue.

Tell me the reason that you judge that quality of the external signal to
optical interface as ADAT sync is enough good and realiable.


Regards

Takashi Sakamoto

Re: CIP Discontinuity with snd-firewire-digi00x

[lin-alsa]

Hi,

Thank you for your quick reply! I greatly admire your code, and I was 
looking at your repo when I was setting this up :) The relavent dmesg 
lines (dmesg | grep fire) are here: http://ix.io/OQ2. I don't know if the 
first bit about the config rom has anything to do with this, but I hope it 
helps, and the hex pairs are in that log.

Re: the clock issue, I'm not actually using optical in, if that's what you 
mean. Please explain what you mean to me, I'm a bit confused as to your 
question.

Lin

On Sun, 5 Jun 2016, Takashi Sakamoto wrote:

> Hi,
>
> I've used the same unit for my development and test.
>
> On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
>> Unfortunately, the mixer seems to desync or something after a few
>> minutes - hours. dmesg gives me `snd-firewire-digi00x fw1.0: Detect
>> discontinuity of CIP: XX XX` with XX XX replaced with various hex
>> pairs.
>
> The hex pairs is important in this log, too.
>
> On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
>> so I don't think it's an external clock issue.
>
> Tell me the reason that you judge that quality of the external signal to
> optical interface as ADAT sync is enough good and realiable.
>
>
> Regards
>
> Takashi Sakamoto
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: CIP Discontinuity with snd-firewire-digi00x

[Takashi Sakamoto]

Hi,

On Jun 5 2016 08:09, lin-alsa@noblejury.com wrote:
> The relavent dmesg lines (dmesg | grep fire) are here: http://ix.io/OQ2.
> I don't know if the first bit about the config rom has anything to do with
> this, but I hope it helps, and the hex pairs are in that log.

It's really my help, great ;)

> Re: the clock issue, I'm not actually using optical in, if that's what
> you mean. Please explain what you mean to me, I'm a bit confused as to
> your question.

Oops. I was dull just after waking up. (it's an exchange for the quick
reply...)

On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
> `Optical mode: adat
> Sampling Rate: 88200
> Clock Source: internal`

Indeed, your unit is set to use internal clock signal as sampling clock.
So no worry about the external signals, sorry.


Well, as long as seeing your log, ALSA digi00x driver detects
discontinuity of data block counter on incoming packets from the unit.
(On IEEE 1394 bus, data is transferred as a form of packet.)
Unfortunately, I cannot reproduce this situation with my unit.

So I think there's two possibility:
1.We work with different drivers; i.e. based on different source code.
2.We work with different state of the unit; i.e. different firmware.

At first, let's confirm the item 1. Could you explain where
snd-firewire-digi00x comes from? Is it from any Linux distribution? Or
you did handy install from somewhere such as my repository in github.com?


Regards

Takashi Sakamoto

Re: CIP Discontinuity with snd-firewire-digi00x

[lin-alsa]

Hi,

Here's the modinfo:

filename: 
/lib/modules/3.18.24-rt22-1-rt-lts/updates/dkms/snd-firewire-digi00x.ko
license:        GPL v2
author:         Takashi Sakamoto <o-takashi@sakamocchi.jp>
description:    Digidesign Digi 002/003 family Driver
alias:          ieee1394:ven0000A07Emo00000002sp*ver*
depends: 
snd-firewire-lib,firewire-core,snd-pcm,snd,snd-rawmidi,snd-hwdep
vermagic:       3.18.24-rt22-1-rt-lts SMP preempt mod_unload modversions

And uname -a for good measure:
Linux archon.umbc.edu 3.18.24-rt22-1-rt-lts #1 SMP PREEMPT RT Thu Nov 12 
22:45:45 CET 2015 x86_64 GNU/Linux

I know I compiled it from your git repo at one point in the past, and I 
think that is the version being used (I'm on a lts kernel).

Lin


On Sun, 5 Jun 2016, Takashi Sakamoto wrote:

> Hi,
>
> On Jun 5 2016 08:09, lin-alsa@noblejury.com wrote:
>> The relavent dmesg lines (dmesg | grep fire) are here: http://ix.io/OQ2.
>> I don't know if the first bit about the config rom has anything to do with
>> this, but I hope it helps, and the hex pairs are in that log.
>
> It's really my help, great ;)
>
>> Re: the clock issue, I'm not actually using optical in, if that's what
>> you mean. Please explain what you mean to me, I'm a bit confused as to
>> your question.
>
> Oops. I was dull just after waking up. (it's an exchange for the quick
> reply...)
>
> On Jun 5 2016 07:30, lin-alsa@noblejury.com wrote:
>> `Optical mode: adat
>> Sampling Rate: 88200
>> Clock Source: internal`
>
> Indeed, your unit is set to use internal clock signal as sampling clock.
> So no worry about the external signals, sorry.
>
>
> Well, as long as seeing your log, ALSA digi00x driver detects
> discontinuity of data block counter on incoming packets from the unit.
> (On IEEE 1394 bus, data is transferred as a form of packet.)
> Unfortunately, I cannot reproduce this situation with my unit.
>
> So I think there's two possibility:
> 1.We work with different drivers; i.e. based on different source code.
> 2.We work with different state of the unit; i.e. different firmware.
>
> At first, let's confirm the item 1. Could you explain where
> snd-firewire-digi00x comes from? Is it from any Linux distribution? Or
> you did handy install from somewhere such as my repository in github.com?
>
>
> Regards
>
> Takashi Sakamoto
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: CIP Discontinuity with snd-firewire-digi00x

[Takashi Sakamoto]

Hi,

On Jun 5 2016 23:22, lin-alsa@noblejury.com wrote:
> I know I compiled it from your git repo at one point in the past, and I
> think that is the version being used (I'm on a lts kernel).

OK. We should check the point in the past.

Please get git-hash of HEAD in your local repository duplicated from my 
remote repository, like:
$ cd your-local-repository
$ git show HEAD
$ commit xxxx....

As a next step, I'd like to update your build so that we can use the new 
feature (tracepoints) recently added to snd-firewire-lib in Linux 
4.7-rc1. I maintain my remote repository for backporting to Linux 3.10 
or later and you could install the latest feature in your 3.18 kernel.


Regards

Takashi Sakamoto

Re: CIP Discontinuity with snd-firewire-digi00x

[lin-alsa]

TZAG,

This issue went away for a while, sorry for the radio silence. I'm now 
running 4.4.17-rt25-1-rt-lts. I believe that the relevant driver was 
merged into mainline since then. I've had a little more time to do some 
debugging, and I've discovered that the mixer connected light goes on
and off a few times before turning off and requiring a hard reboot.

Best,

Lin

On Mon, 6 Jun 2016, Takashi Sakamoto wrote:

> Hi,
>
> On Jun 5 2016 23:22, lin-alsa@noblejury.com wrote:
>>  I know I compiled it from your git repo at one point in the past, and I
>>  think that is the version being used (I'm on a lts kernel).
>
> OK. We should check the point in the past.
>
> Please get git-hash of HEAD in your local repository duplicated from my 
> remote repository, like:
> $ cd your-local-repository
> $ git show HEAD
> $ commit xxxx....
>
> As a next step, I'd like to update your build so that we can use the new 
> feature (tracepoints) recently added to snd-firewire-lib in Linux 4.7-rc1. I 
> maintain my remote repository for backporting to Linux 3.10 or later and you 
> could install the latest feature in your 3.18 kernel.
>
>
> Regards
>
> Takashi Sakamoto
>

Re: CIP Discontinuity with snd-firewire-digi00x

[Takashi Sakamoto]

Hi,

On Sep 1 2016 09:52, lin-alsa@noblejury.com wrote:
> This issue went away for a while, sorry for the radio silence. I'm now
> running 4.4.17-rt25-1-rt-lts. I believe that the relevant driver was
> merged into mainline since then.

The firewire-digi00x module was exactly merged to Linux 4.4. See:
https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Linux_4.4

> I've had a little more time to do some debugging, and I've discovered
> that the mixer connected light goes on and off a few times before
> turning off and requiring a hard reboot.

Hm. I have never experienced this kind of issue. For my information,
please show your OHCI 1394 host controller? Typically, 'lspci' is good
for this purpose.

For your information, I wrote 'hinawa-dg00x-cui' for this series of
units. It's in my repository in github.com:
https://github.com/takaswie/hinawa-utils

If you install libhinawa, gir1.2-hinawa-1.0, Python3 and PyGobject, the
command allows you to control your unit somewhat. For example, when you
change the mode of optical digital input interface, please run:
$ ./hinawa-dg00x-cui 1 optical-interface set ADAT

You can see all of sub-commands:
$ ./hinawa-dg00x-cui 1

And see parameters for each sub-commands just by run with the sub-command:
$ ./hinawa-dg00x 1 optical-interface

ALSA digi00x module still has several issues, but I think you have no
interests in it and don't address to it.


Regards

Takashi Sakamoto