Created attachment 275297 [details] Alsa info Focusrite Saffire 26/IO, Get's to constant boot/reset loop.
Created attachment 275299 [details] Pulseaudio log
Created attachment 275301 [details] Dmesg capture Synced with pulseaudio log
Hi, I'm an author of ALSA bebob driver and sorry to catch up with this issue. Your unit, 'Focusrite Saffire 26 I/O' is one of my test device as well as '10 I/O'. > repeating bus resets on Firewire bus with Focusrite Saffaire 26/io Yes. The combination with ALSA bebob driver and PulseAudio brings this issue, due to a quirk of these devices. When detecting sound cards, pulseaudio process loads 'module-alsa-card'. This module starts PCM substreams via ALSA PCM interface to detect available parameters of the runtime; e.g. channels, rates and so on. It keeps the substream during 5 seconds, then stops it. When requested to start/stop any PCM substream, ALSA bebob driver handles the devices to start/stop packet streams. This operation is managed as 'connection' as CMP described in IEC 61883-1. The devices have a quirk relevant to the connection. When requested to break established connections, your device has a quirk to stop packet streaming, then generate bus reset. This is not specific feature only with ALSA bebob driver, but also with any windows driver. To suppress the repetitive bus resets, it's only way to discourage PulseAudio to handle these two devices. But no one works for it.
> The devices have a quirk relevant to the connection. When requested to break > established connections, your device has a quirk to stop packet streaming, > then generate bus reset. This is not specific feature only with ALSA bebob > driver, but also with any windows driver. Oops. As a supplement, the devices not only generate bus reset. Once they disappear from IEEE 1394 bus then re-appear to the bus and bus reset occurs. In a view of system, your device looks to be un-plugged then plugged-in. Then your device is newly detected and probe processing in relevant appliations runs again. This is a reason that you observed repetitive bus-reset. $ cat dmesg.log ... [91244.190833] firewire_core 0000:03:00.0: created device fw2: GUID 00130e0100030de5, S400 ... [91249.630016] firewire_core 0000:03:00.0: created device fw2: GUID 00130e0100030de5, S400 ... [91352.666268] firewire_core 0000:03:00.0: created device fw2: GUID 00130e0100030de5, S400 ... [91391.383576] firewire_core 0000:03:00.0: created device fw2: GUID 00130e0100030de5, S400 ... [91417.338661] firewire_core 0000:03:00.0: created device fw2: GUID 00130e0100030de5, S400 ...
(In reply to Takashi Sakamoto from comment #3) > Hi, > > I'm an author of ALSA bebob driver and sorry to catch up with this issue. > Your unit, 'Focusrite Saffire 26 I/O' is one of my test device as well as > '10 I/O'. > > > repeating bus resets on Firewire bus with Focusrite Saffaire 26/io > > Yes. The combination with ALSA bebob driver and PulseAudio brings this issue, > due to a quirk of these devices. > > When detecting sound cards, pulseaudio process loads 'module-alsa-card'. This > module starts PCM substreams via ALSA PCM interface to detect available > parameters of the runtime; e.g. channels, rates and so on. It keeps the > substream during 5 seconds, then stops it. > > When requested to start/stop any PCM substream, ALSA bebob driver handles > the devices to start/stop packet streams. This operation is managed as > 'connection' as CMP described in IEC 61883-1. > > The devices have a quirk relevant to the connection. When requested to break > established connections, your device has a quirk to stop packet streaming, > then generate bus reset. This is not specific feature only with ALSA bebob > driver, but also with any windows driver. > > To suppress the repetitive bus resets, it's only way to discourage > PulseAudio to handle these two devices. But no one works for it. I don't mind taking this as a challenge. do you have any suggestion on how to handle this quirk from within PulseAudio ?
> I don't mind taking this as a challenge. do you have any suggestion on how to > handle this quirk from within PulseAudio ? As I noted, this quirk brings problems to pulseaudio because pulseaudio start/stop PCM substream when detecting these devices. This mechanism is: 1. udevd catches kevent about these two events, then send messages to listers via IPC. 2. in pulseaudio, 'module-udev-detect' module handles the message, then load 'module-alsa-card'. 3. 'module-alsa-card' calls 'pa_alsa_sink_new()' in 'module-alsa-sink' for playback PCM substream or 'pa_alsa_source_new() in 'module-alsa-source' for capture PCM substream. 4. 'pa_alsa_sink_new()' and 'pa_alsa_source_new()' keeps a POSIX thread to perform actual I/O for the PCM substream, then parameters are retrieved from runtime of the PCM substream. 5. pulseaudio let these threads suspend when no clients request data stream during 5 seconds. 6. when suspending, PCM substreams are stopped. This causes these devices to disappear from 1394 bus and generate bus reset, then re-appear to 1394 bus. 7. back to 1. Therefore we need to discourage PulseAudio not to start/stop PCM substream automatically for these devices when detecting them. In my opinion, the simplest way is take pulseaudio not to load 'module-alsa-card' for them. I don't know exactly pulseaudio already has some solution to suppress it.
After I consulted with the pulseaudio guys we have a solution: Unloading the following pulseaudio module - module-suspend-on-idle - saves the day. Temporarily: 'pactl unload-module module-suspend-on-idle' Permanently: '/etc/pulse/default.pa'
Aha. I didn't realize that 'module-suspend-on-idle' has the effect, thanks. > Temporarily: 'pactl unload-module module-suspend-on-idle' > Permanently: '/etc/pulse/default.pa' But in my opinion this is not a expected solution because the devices are designed for studio usage. I can easily imagine that owners would like to use them with Jack Audio Connection Kit rather than PulseAudio. Your solution let pulseaudio handle the devices always, thus the other processes like jackd can't handle them via ALSA PCM character devices. Any complaint to PulseAudio from jackd users are expected, sign... I's better to suppress pulseaudio to handle them automatically, as I noted. If owners need to use them with pulseaudio, then load 'module-alsa-sink' and 'module-alsa-source' by hand.
A fix was committed. alsa: Suppress udev detection of sound card for some units on IEEE 1394 bus https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/37358e42c49abe3d83b344452749461b70fdc80f Thanks.