[alsa-devel] CIP Discontinuity with snd-firewire-digi00x
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
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
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
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
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
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
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
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
participants (2)
-
lin-alsa＠noblejury.com -
Takashi Sakamoto