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

Periodic interrupts with Digidesign Digi 002 Rack #31

Closed alesandar closed 3 years ago

alesandar commented 3 years ago

Today I've got a decent deal for a Digidesign Digi 002 Rack, so I decided to get it, primarily for testing purposes. It seems like it has the same problem, as we've previously discussed in #27. #26 seems to be pretty much the same. Can you confirm if all three issues are actually caused by #24?

takaswie commented 3 years ago

Can you confirm if all three issues are actually caused by #24?

The mechanism is completely different depending on the devices even if the behaviour is superficially similar.

In Digidesign Digi 00x family, each isochronous packet transfers no information about timing synchronization, as I described at #24.

In MOTU FireWire series, each data block in isochronous packet has information about timing synchronization in its sph field. I understand that the sequence of value in sph field is used for synchronization by SMPTE time code[1][2][3] or synchronization between multiple devices on the same bus.

Anyway, the sequence of isochronous packet has the amount of sampling data. In my opinion, the amount is itself important because it represents the amount of sampling data transferred via internal data bus from packet processing part to the other part; e.g. digital audio processing part in DSP, CPLD and FPGA. I guess that the pop noise comes from timing mismatch against the data bus.

ALSA IEC 61883-1/6 packet streaming engine transfers isochronous packets with sampling data as exactly the same as current sampling transmission frequency according to IEC 61883-1/6. If the internal data bus is not designed to deliver sampling data from the packet processing part to the others, it could causes some missing samples, I guess.

I continue to work for ALSA firewire stack. My recent work adds preparation to use the amount in incoming packet stream for outgoing packet stream[4]. However the work is not done yet.

[1] https://motu.com/products/motuaudio/traveler-old/smpte.html [2] https://motu.com/products/motuaudio/8pre/smpte.html [3] https://motu.com/products/motuaudio/copy_of_ultralite/smpte.html [4] https://mailman.alsa-project.org/pipermail/alsa-devel/2020-May/167447.html

StrictAvacado commented 3 years ago

hi I am using a digidesign 002r with a TI XIO2213B with reaper . so far i have not experienced any issues. I am testing with kde neon with kernel 5.4.0-60-generic. I wonder if some of the issues other people are having are caused by the firewire chipset silicon?

alesandar commented 3 years ago

@StrictAvacado, are you using jackd with Reaper? If yes, then are you sure that your jackd is not reporting any xruns? I have performed tests on many different machines, with different chipsets and peripherals (external PCMCIA cards w/ VIA, internal Texas Instruments and Ricoh chipsets, etc). The issue was 100% reproducible everywhere.

takaswie commented 3 years ago

@alesandar Hm. In development period for Linux kernel v5.5, I've added many changes to IEC 61883-1/6 packet streaming engine in ALSA firewire stack. If the issue were a kind of regression, it have come from the change. Would I request the kernel version which you use?

alesandar commented 3 years ago

That system is not in front of me right now, but the kernel version is definitely higher than 5.6.8, since I have reported my initial MOTU 828mk3 issue on Apr 30, 2020 (running 5.6.8 back then). I could check the exact version later, if it matters.

takaswie commented 3 years ago

@alesandar Thanks. The kernel you use seems to include the changes.

$ git log --oneline v5.3..v5.4 sound/firewire/ | wc
     54     541    4135
$ git log --oneline v5.4..v5.5 sound/firewire/ | wc
     54     624    4228
$ git log --oneline v5.5..v5.6 sound/firewire/ | wc
      9      74     541

One of aim of the change is to introduce arrangement of the period of hardware interrupt according to the size of period in PCM buffer configured by userspace application. It's done in v5.5. Before the change, hardware interrupt of 1394 OHCI controller is scheduled every 2 millisecond (= 16 packets/8000 cycles) and the size of period in PCM buffer is not used for it.

At present, I use my time to work for userspace service program for control of Audio and Music units in IEEE 1394 bus[1], thus it's postponed to investigate the issue, sorry.

[1] https://github.com/alsa-project/snd-firewire-ctl-services/

StrictAvacado commented 3 years ago

I am just using pulseaudio at the moment. and I can't hear any audible deference between linux and the windows driver and i can't see any pulses or dropout in my recording in reaper. I will testout jackd and see more I can learn. and for more info I am using a ryzen 3200g with dual channel ram and the firewire interface is a pcie card.. I am not sure if it going directly to the cpu or if it is connected to a slot that goes through the chipset. also, I am using a firewire 800 to 400 cable.

alesandar commented 3 years ago

The dropouts are not that audible, depending on what you're recording. If you have an equipment that can produce a low-frequency sine wave, you will easily consider how the cycle of the wave will be interrupted at some point and that will happen again, and again, periodically. Audacity could mark the dropouts. Reaper does not have that capability, as far as I know. The issue is worse if you run jackd in asynchronous mode (the default JACK2 mode). I have experienced and reported the same type of issue with MOTU 828mk3. It happens only in duplex mode, meaning that you have to initialize both capture and playback channels.

takaswie commented 3 years ago

I attempt to implement media clock recovery to suppress the issue. If still interested, please test current HEAD of topic/media-clock-recovery remote branch (3a2c5fd52657).

For jackd, I recommend to use -S option.

alesandar commented 3 years ago

Hello, @takaswie. I have tested the current HEAD of topic/media-clock-recovery. It seems like you might have found a workaround. Congratulations!

I will provide more details during the next few days. In the meanwhile, here are some journalctl error logs that were printed, while JACK was being initialized.

[   87.515933] snd_firewire_digi00x fw1.0: association: 0 <- 1
[   87.521459] snd_firewire_digi00x fw1.0: 42315: 0:0 callbacked
[   87.521482] snd_firewire_digi00x fw1.0: 42357: expected to rx start
[   87.526831] snd_firewire_digi00x fw1.0: 42357: 0 starts
[   87.542792] snd_firewire_digi00x fw1.0: 42363: 1:1 callbacked
[   87.542813] snd_firewire_digi00x fw1.0: 42399: expected to tx start
[   87.548166] snd_firewire_digi00x fw1.0: 42399: 1 starts
[ 1107.372979] snd_firewire_digi00x fw1.0: association: 0 <- 1
[ 1107.383796] snd_firewire_digi00x fw1.0: 9389: 0:0 callbacked
[ 1107.383827] snd_firewire_digi00x fw1.0: 9474: expected to rx start
[ 1107.394550] snd_firewire_digi00x fw1.0: 9474: 0 starts
[ 1107.426440] snd_firewire_digi00x fw1.0: 9481: 1:1 callbacked
[ 1107.426454] snd_firewire_digi00x fw1.0: 9559: expected to tx start
[ 1107.437093] snd_firewire_digi00x fw1.0: 9559: 1 starts
takaswie commented 3 years ago

Hi @alesandar,

I have tested the current HEAD of topic/media-clock-recovery. It seems like you might have found a workaround. Congratulations!

Nice to hear it.

I will provide more details during the next few days.

I'm looking forward to your report with MOTU device.

In the meanwhile, here are some journalctl error logs that were printed, while JACK was being initialized.

The error message is convenient to my debug, which is added in the commit at HEAD of the remote branch. Just ignore it.

Thanks

alesandar commented 3 years ago

I'm looking forward to your report with MOTU device.

Unfortunately, I won't be able to test my MOTU during the next few days, because of a common circuit fault. Hopefully, I will have to replace only one or two capacitors and once I do it, I will definitely let you know.

Regarding my tests from yesterday, I have started JACK with the following settings: 48000/512/3. Then I have started speaker-test and left my system playing white noise for five hours, while I was away. When I came back, the noise was still playing and JACK did not reported any xruns. The DSP load was really low, but when I reported the issue, the periodic interrupts were present in this circumstances as well.

By the way, I have started the JACK process with -S, --shorts argument, but why did you recommended to do so?

takaswie commented 3 years ago

By the way, I have started the JACK process with -S, --shorts argument, but why did you recommended to do so?

Ah, the -S option is for jackd runtime itself for --sync feature, see: https://github.com/jackaudio/jack2/issues/736

We need to append --sync option before --driver option.

alesandar commented 3 years ago

Yeah, I supposed that you might be talking about the --sync option, but I did not know that it could be defined as capital -S. I have always used your drivers in --sync mode. Without it, instead of a single xrun, I have been getting bursts of a few hundred xruns. Thank you for making it clear. As far as I know, --sync is the only available mode with JACK1 and that might be the reason for some people to have problems with JACK2, but not with JACK1.

takaswie commented 3 years ago

I note that patchset is posted to upstream:

takaswie commented 3 years ago

The patchset is merged to upstream. The patches are also available in master branch of the repository. Let me close the issue. Thanks for your cooperation.

takaswie commented 3 years ago

P.S. The service program to control the device is available. Please refer to below URL if you are interested: