Bug 199365 - repeating bus resets on Firewire bus with Focusrite Saffaire 26/io
Summary: repeating bus resets on Firewire bus with Focusrite Saffaire 26/io
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-12 02:26 UTC by Ramon Fried
Modified: 2018-08-24 10:05 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.13.0-38
Tree: Mainline
Regression: No


Attachments
Alsa info (64.55 KB, text/plain)
2018-04-12 02:26 UTC, Ramon Fried
Details
Pulseaudio log (957.56 KB, text/plain)
2018-04-12 02:28 UTC, Ramon Fried
Details
Dmesg capture (4.83 KB, text/plain)
2018-04-12 02:29 UTC, Ramon Fried
Details

Description Ramon Fried 2018-04-12 02:26:31 UTC
Created attachment 275297 [details]
Alsa info

Focusrite Saffire 26/IO, Get's to constant boot/reset loop.
Comment 1 Ramon Fried 2018-04-12 02:28:37 UTC
Created attachment 275299 [details]
Pulseaudio log
Comment 2 Ramon Fried 2018-04-12 02:29:08 UTC
Created attachment 275301 [details]
Dmesg capture

Synced with pulseaudio log
Comment 3 Takashi Sakamoto 2018-05-01 00:14:14 UTC
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.
Comment 4 Takashi Sakamoto 2018-05-01 00:33:34 UTC
> 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
...
Comment 5 Ramon Fried 2018-05-01 10:50:04 UTC
(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 ?
Comment 6 Takashi Sakamoto 2018-05-02 09:26:48 UTC
> 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.
Comment 7 Ramon Fried 2018-05-09 19:16:26 UTC
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'
Comment 8 Takashi Sakamoto 2018-05-09 23:38:26 UTC
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.
Comment 9 Takashi Sakamoto 2018-08-24 10:05:57 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.