search

takaswie / linux-firewire-dkms

Currently this repository is maintained for Linux firewire subsystem and unit drivers.
http://ieee1394.docs.kernel.org/
39 stars 8 forks source link

saffire pro 40 - tries to connect but fails #45

Closed dreamcat4 closed 1 year ago

dreamcat4 commented 2 years ago

hi there, just plugged this in today. trying to make it work. What I see here is that some status leds flashes on the front panel of the interface, this happens just before the user login screen pops up.

However unforunately there seems to be some sort of communications error. And the device does not appear after logging into desktop session, after loading pipewire etc.

[id:~] 130 $ sudo dmesg -w|grep fw
[    1.470466] firewire_core 0000:03:00.0: created device fw0: GUID 0011223333555555, S400
[    4.591494] firewire_core 0000:03:00.0: created device fw1: GUID 00130e0401404f10, S400
[    4.742627] snd_hda_intel 0000:00:1f.3: Applying patch firmware 'hda-jack-retask.fw'
[    4.742777] snd_hda_intel 0000:01:00.1: Applying patch firmware 'hda-jack-retask.fw'
[   26.387768] snd_dice fw1.0: Detect discontinuity of cycle: 11297 11298
[   26.677842] snd_dice fw1.0: Detect discontinuity of cycle: 13700 13701
[   26.936997] snd_dice fw1.0: Detect discontinuity of cycle: 15782 15783
[   27.374312] snd_dice fw1.0: transaction failed: bus reset
[   27.424313] snd_dice fw1.0: transaction failed: bus reset
[   27.476329] snd_dice fw1.0: transaction failed: bus reset
[   27.526348] snd_dice fw1.0: transaction failed: bus reset
[   27.576322] snd_dice fw1.0: transaction failed: bus reset
[   27.628304] snd_dice fw1.0: transaction failed: bus reset
[   27.928326] snd_dice fw1.0: transaction failed: bus reset
[   27.978300] snd_dice fw1.0: transaction failed: bus reset
dreamcat4 commented 2 years ago

ah interesting... maybe it was just the cable. i replace the 2m cable with a shorter one. and power cycle everything. it is now recognized and appearing

however i would like to keep this issue open for the time being. because there might be other issues (for example kernel panic later on, possibly)

takaswie commented 2 years ago

Hi,

Thanks for your reporting it.

however i would like to keep this issue open for the time being. because there might be other issues (for example kernel panic later on, possibly)

I don't mind it, keep opened. Feel free to post your notice when finding any issue.

dreamcat4 commented 2 years ago

this report is a mess sorry. because i am not sure yet what is really the underlying problem exactly.

but in the meantime, here is a more detailed journal / log describing all of my failed activities so far. because i want to move on to try changing other things. so am writing down here in case i forget any important detail of these previous failures / attempts....

initial steps:

1st times (first 1-3 boots) the 2m cable had a few discontinuity errors in dmesg. then the interface did connect and appear in pipewire. (that was on 5.17 kernel but without building and installing your dkms from git here).

1st problem i saw was when connecting the first 1-2 input channels inside qpwgraph gui tool (for pipewire). i connect them to my daw bitwig. which is running jack as the audio engine (pipewire jack library override). after connecting them a few seconds later the whole computer freeze. like a kernel crash. not response to switch tty or see any message. the whole computer fully locked up, and the mouse pointer not move anymore

this is a mess. anyhow the original 2m cable it stopped recognizing the saffire pro 40 entirely. and for multiple reboots. so that was my oriignal report. to say i switched the cable to 1m

part 2)

^ changed the cable

clearly i was troubled be the hard lockups

part 3)

last night:

my other observations so far:

ffado-mixer

power cycling

this seems really invonvenient. so it would be helpful to just power off / on the saffire pro 40 first, (then rebboot the pc). however there is a large yellow warning sticker on the interface. saying not to disconnect / reconnect the firewire cable while the pc is powered on

now strictly speaking. i would not be touching the cable. in order to power cycle the saffire while the pc was switched on. however it is not clear (to me) whether that amounts or not to being the same thing. since the firewire chip (dice jr) inside of the saffire is then passively connected hanging to the host. while power cycling the saffire on --> off --> on

so if that is not safe, then maybe there is a way to just pulse the reset lines inside the saffire (hard modding), so that the saffire can soft reset itself without cutting power? since we have the datasheets for all of those chips

i think i also want to order a spare firewire chip. but they seem difficult to find (those TC Applied Technologies TCD2220 aka "Dice Jr").

===

what i am really struggling with is what to do next. because there so many options. are a lot of different things to try to investigate. but maybe the first thing will be to stop connecting the saffire directly to bitwig's jack channels. in case jack or bitwig is the problem. so i will next instead try connecting to other types of pipewire nodes (for example pulse audio, or other 'alsa hardware' node).

maybe there are other things can try too. for example boot into a different kernel, one that is not my current kernel (xanmod 5.17)

but if you have any other suggestion. or want me to take some specific logging or doagnostic test. please let me know! it could save a lot of time, to not to focus on the wrong things. (since this is my first experiences with firewire. i really do not know what i am doing here!)

many thanks

takaswie commented 2 years ago

Hm.

Would you show me the configuration of kernel in your system? You can find it in /boot/config-xxx.

I know that Linux driver for 1394 OHCI controller has an issue when running with linux-rt kernel, see:

If your system uses such kind of Linux kernel, the driver probably has such kind of transaction error since bottom-half of driver processing is enough delayed due to timing issue. (and this kind of issue is hard to find the cause.)

Regards

dreamcat4 commented 2 years ago

https://gist.github.com/dreamcat4/44418151b3b3b87782132ab01fe65c71

dreamcat4 commented 2 years ago

right sorry, got distracted and had to spend half the day away doing other things....

my current problem: (pipewire process locks up fully, when connecting the saffire pro 40). This problem still exists (for me). However I can now say: it is only with this bitwig-studio verison (which is 4.0.1). And not with other audio programs. And the kernel choice - it does not seem to matter. at least as far as those kernels which i was able to test here, because i could not get the mainline ubuntu kernels to work, which had some other type of an issue, it cannot get as far to show the graphical gui login screen of SDDM, to log in to the DE.

anyhow here is an update of my progress:

3rd test:

results:

tentative conclusion

The thing about bitwig studio however is... we could try to look into what is the matter. But they already announced that for future versions of bitwig (still in beta, but going forwards next versions). That they will be adding a native support for pipewire audio backend. So it does not necessarily make sense to spend resources to get working the current (older version) of bitwig in jack mode. It makes more sense to skip that and be waiting for future verison of bitwig, and upgrade it. Then later on retest, to see if the bug is still there, or if the bug is solved by switching fully to the native pipewire backend.

However it might be nice while I am in this situation, to try to take some extra logging of the pipewire crash condition. I can do this from pipewire's side by setting PIPEWIRE_DEBUG=5 (or =6). And it will produce reams and reams of many trace log, and generate some huge logfile (several GBs textfile).

But if you have any better suggestions for how to generate some better useful and relevant logging. That is more usable, and is not so overwhelming? Then please let me know, so I can go back and try to capture those more specific logging. If it is of any value / any interest to investigate any further from your side (or from pipewire team side).

dreamcat4 commented 2 years ago

Next I would like to ask the situation with ffado-mixer and 96khz mode. If it's not supported, that it should not work? Or could it be possible to configure the DSP routing on this device?

Because when I look at the changelog nodes for libffado... it does not really seem to mention much recent activity in regards to saffire pro 40 device. Only it mentioned other saffire models, like the pro24 (or pro26, which ever other ones). So I do not assume it works properly. But if it should be working and I am wrong? ... then please let me know! Since to be able to re-route the channels. It is quite a useful feature to have in linux. So to not be needing another different PC, and be configuring it from the windows or macOS software. As do not have any other such machines with firewire bus, (only this linux PC has the firewire card, no other computers can talk to it).

BTW many thanks for working on these firewire kernel stack @takaswie. It's a great service to the community. And so sorry for reading such poor bug report, it (as does not include so much useful information to act upon).

dreamcat4 commented 2 years ago

quick update:

ran out of time today, but tomorrow can try some other things, for example to disable the intel (built in motherboard audio) at the bios level, or maybe some other things, or to ask for extra advice from the pipewire team

but it is a good news, and I hope to continue investigating what else other things can / cannot work for this firewire audio. (maybe go back to the ffado tools also)