HI,
On Oct 13 2015 07:20, Jonathan Woithe wrote:
On Mon, Oct 12, 2015 at 02:48:16PM +0200, Stefan Richter wrote:
On Oct 12 Takashi Sakamoto wrote:
Although TASCAM FireWire series has physical controls, this patchset doesn't support them. I think some facilities are required to enable this functionality:
- handling MIDI messages on virtual MIDI ports by this driver
- handling status and control messages in isochronous packet by this driver
As a side note, AFAIR, RME devices encapsulate status in their isochronous stream too... or was it MOTU?
Both do, but in completely different ways for different purposes. In the case of RME devices the information communicated can be used to help control and monitor the streaming system but it is not essential: there are other arguably easier ways to maintain the streaming rates, and these alternatives are what we use in FFADO now.
In MOTU devices the information relates mainly to device control changes which are made via the front panel controls. This is used to keep software mixer/control programs in sync with the hardware when changes are made on the hardware while the software control application is running. It sounds like this is close to what the Tascam units do based on Takashi's comments (although obviously with a very different protocol).
(In this message, I mention about the other issues because of its priority, sorry.)
I don't know the reason that you're interested in it, while I'm not currently interested in it.
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.
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
If possible, I'd like to add enough rules to udevd, including RME and MOTU models before working for them.
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'm glad to get your help for these issues, Stefan and Jonathan.
Regards
Takashi Sakamoto