Hi Stefan,
Sorry to be late for reply, but I have some works to ALSA firewire stack. Furthermore, it takes me a bit time to write messages because I always start to write after enough consideration, investigation and arrangement about the point of issues.
On Oct 13 2015 23:15, Stefan Richter wrote:
I was just generally wondering what the extent of protocol similarities are. Personally I don't own a Digidesign, TASCAM, RME or MOTU at this time. Thanks to you and to Jonathan for explaining.
These protocols use different format of data block, while I guess that the number of data blocks transferred per second and the number of data blocks in packets follow to IEC 61883-6. In this developing period, I re-design AMDTP functionality in firewire-lib according to this assumption.
When the status and control messages are handled by the drivers, consumers are userspace applications. Userspace applications perform some reactions against the status and control messages. Most of the reactions are archieved via fw character devices.
(Of cource, I know there're some requirements for drivers to perform such responsibilities, instead of userspace applications. But it's a rare case, I think.)
When considering about userspace applications, permissions of fw character devices are important. Thus, 'udevd' in systemd project has enough rules for userspace applications to handle IEEE 1394 units for audio and sound.
Many of the udev rules which concern audio devices are actually maintained in the FFADO project and thus installed by the FFADO package (or by installing FFADO from source), in contrast to the usual way of keeping udev rules in the udev/systemd project and installing them via an udev package.
FFADO is of course not unique in this regard. As an example, the following packages are providing files in /lib/udev/rules.d/ on my current desktop installation: alsa-utils, consolekit, fuse, kino, libffado, libgphoto2, libwacom, lvm2, media-player-info, netifrc, ntfs3g, sane-backends, udev, udisks, upower-pm-utils. And of course I have site-specific rules in /etc/udev/rules.d/ too.
It's just for units supported by FFADO project, while udev has its rule for ALSA sound cards.
https://github.com/systemd/systemd/blob/master/rules/78-sound-card.rules
When considering about the requirement of permissions for fw character devices for the units, adding more rules for them is valuable. At least, it's good to discuss about it, I think.
In the series of the patchset, I committed for some models which Digidesign and TASCAM produced. Unfortunately, there're no rules for these models. Userspace applications are disabled to access these units. I believe this issue is prior to handling status and control messages.
Besides, I think this is a main issue which Damien Zammit faced in this post:
[alsa-devel] firewire mixer interface -- was Re: [PATCH 11/11] ALSA: digi00x: apply double-oh-three algorism to multiplex PCM samples http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089381.html
A developer of a mixer program which requires access to /dev/fw* has a few options:
- During early development, he could ask his testers to put a tentative rule into /etc/udev/rules.d/ themselves.
- If the program is being developed as part of the FFADO project, necessary rules should obviously be added to 60-ffado.rules.
- Otherwise the rules could be maintained and packaged together with the mixer program.
- Or the rules could be submitted to the udev/systemd project.
Going the mainline udev route will naturally ensure that the rules conform to standard practice, and that may make the lives of distributors, admins, or users easier.
I'll continue to have cooperative relationship to FFADO project, while, to tell the truth, I'm not willing to add my mixer/control programs to the project anymore for several reasons:
* code base is too old. * Especially for python3 support. Many distributions start to suppress python2 supports and near future ffado packages may be grouped as 'deprecated'. * over-specification * For most of mixer/control applications, it's just enough to send/receive asynchronous transactions. On the other hand, FFADO framework force developers to implement more codes unrelated to it. For example, D-Bus programming. * Libffado also includes streaming functionality and this is used to jackd. It's not so easy to modify without regressions, especially discover routine. * defectives as service application for IEEE 1394 bus * Libffado cannot handle bus-reset correctly, thus libffado cannot handle device hot-plugging. Although, ffado-dbus-server performs as system service. This is due to wrong usage of libraw1394 API.
But this is in my case. In this thread, it's better to continue to discuss with ignoring it.
If possible, I'd like to add enough rules to udevd, including RME and MOTU models before working for them.
For those RME and MOTU models whose mixer program continues to be developed in the FFADO project, the FFADO-maintained ruleset is obviously sufficient.
As long as mixer/controls programs are developed by FFADO project only.
Here, I don't mean that I will do it. But it's disadvantage to persons who like simpler applications. For such users, FFADO stuffs are not always needed, especially for no-GUI users. I've got several messages from such users and reccomend to use 'firewire-request' in linux-firewire-tools package. For such users, it's better to add the rules for fw character devices.
Well, for udevd, current ALSA firewire stack has another issue. It's 'device database' for IEEE 1394 units.
Currently, the database has entries with vendor/model name of OHCI 1394 host controller for any IEEE 1394 units. It's preferrable to use vendor/model name of each units, at least for audio and sound.
PulseAudio includes a patch for this issue. It has additional conditions to select correct strings for IEEE 1394 units. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=3ac73598c67cb59...
If possible, I'd like to remove this ugly patch by working in udevd upstream.
I saw the message which David Henningsson copied to linux1394-devel on February 16 but did not react---and have not noticed the issue before---, as I don't have pulseaudio installed on my own PCs yet. It's probably the wrong place to ask, but: Why do they generally prefer ID_{VENDOR,MODEL}_FROM_DATABASE over ID_{VENDOR,MODEL}? I guess the former is more reliable or nicer on some other buses.
Yep. I also have the same opinion about PulseAudio implementation. I guess there're some reasons shared to PulseAudio/udev/systemd developers, not to us.
I will have a look at the libudev sources whether the _FROM_DATABASE results can be improved for firewire.
Which lines?
Thanks
Takashi Sakamoto