takaswie
commented
4 years ago Hi,
Today I use my Thinkpad T420 and the same device (828mk3 FireWire only). Although I can see XRUNs each several hundreds seconds in a case of 192.0 kHz, 512/1024 frames/period and 2-4 periods/buffer, I cannot see periodicity based on the size of buffer.
My equipments:
- Machine
- Thinkpad T420
- CPU
- Intel Core i5-5220M (2.5GHz)
- Hyperthreading off
- 1394 OHCI controller
- on-board (1180:e832, Ricoh R5C832)
- Sonnet FireWire 800 Pro ExpressCard 34(104c:823f, Texus Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express])
- Ubuntu 20.04 amd64
- Linux kernel 4.3
- ALSA firewire stack
- from Ubuntu repository
- https://github.com/takaswie/snd-firewire-improve
For 1394 OHCI controller and ALSA firewire stack, I used two options for each, however I cannot find any difference between them.
In this trial, I turned hyperthreading off. Would I request you to test again without hyperthreading? In my understanding, hyperthreading loads cores and easily brings jitter for IRQ handling.
alesandar
I am experiencing an issue with my MOTU 828mk3 (JACK2 with ALSA backend). A periodic xrun occurs every now and then and the interval seems to be dependent on the buffer size.
During all of the following tests, sample rate and nperiods have been set to 192000/3. For some reason I can not set lower sample rate values. [1] Only the buffer size has been changed after each test. Please consider the corresponding intervals.
$ tail -f ~/.log/jack/jackdbus.log | grep alsa_pcmbuffer size: 2048 (~349s interval between xruns):
buffer size: 1024 (~344s interval between xruns):
buffer size: 512 (~81s interval between xruns):
buffer size: 256 (~81s interval between xruns):
buffer size: 128 (~15s interval between xruns):
I know that this messages does not contain very accurate timestamps, but they might be of some help, since
$ dmesg -wwas completely silent about the interrupts. [2][1] Trying to initialize the interface at other sample rates usually causes the following error:
Power-cycling the interface and reloading firewire-ohci and snd-firewire-motu might not be enough to get it back working. It seems like JACK is unable to reinitialize the server until I reboot my laptop. At that point, if I try to manually start jackd with sample rate parameters, the sample rate LEDs on the interface change accordingly. Sometimes I can even hear a high-pitched signal while trying to initialize the JACK server with low sample rate settings. However, I usually rely on the JACK2's dbus system by executing jack_control commands.
I have also noticed that jack has to be started in synchronous mode, which is not a default option for JACK2. Otherwise the interval between xruns seems to be the same, but they are a lot more... like hundreds. Realtime priorities does not seem to make a change.
The tests above were performed from within a tty, without a graphical environment. I have disabled services like systemd-timesyncd, removed network modules and so on.
CPU scaling governor was set to performance. Both
/sys/class/rtc/rtc0/max_user_freqand/sys/class/rtc/rtc0/max_user_freqare set to 2048. I have also tried running different kernels, distributions and so on, but things are usually worse.[2] I have recompiled linux (without the realtime kernel patchset) and enabled CONFIG_SND_PCM_XRUN_DEBUG, CONFIG_SND_VERBOSE_PROCFS, CONFIG_SND_DEBUG. Here's some relevant output from dmesg that occured after a single xrun.
I feel like all of this might not be related to my system, but the internal clock of the interface. Any ideas?
system details: laptop: Lenovo Thinkpad T420 CPU: Intel i7-3720QM FireWire chip: Ricoh R5C832 OS: Arch Linux (linux-rt 5.6.4-rt3-1-rt)