From: Takashi S. <o-t...@sa...> - 2014-09-09 20:47:13
|
Hi Jonathan, Thanks to answer my questions. On Sep 8 2014 16:51, Jonathan Woithe wrote: >> > OK. So the driver MUST pick up the nuber of data blocks from >> > incoming-packets for outgoing-packets, right? > Sort of. Within limits it's up to the driver but the numbers currently used > in FFADO are, for various reasons, but better ones to choose. Hm. So ALSA RME driver should always starts incoming-stream for outgoing-stream. Therefore there is no need to get source of clock. Therefore, when getting current sampling frequency, the driver can start streaming. > Pretty much the entire device configuration must be known by all components > which manipulate the device, which includes that which starts the streaming. > On the RME devices the full configuration state is transferred to the device > in a single block every time there is any change to the device's > configuration. This includes some details related to the streaming setup. > As a result, the kernel driver will need to maintain (and provide to > userspace) a copy of the device configuration. This includes but is not > limited to: > - phantom power status > - various gain-related options > - clocking options (which impacts on sample rate control) > - the TCO settings > - SPDIF and ADAT I/O mode options (which also affect the number of channels > in the audio stream) > - audio limiter control > - control over the number of channels being sent/received > and probably a few more that I can't recall off-hand. While only some of > this applies to streaming, it is not possible to control only these specific > options; the entire configuration must be written ever time something > changes. Are there really no way to get current sampling frequency from devices? In my opinion, such parameters unrelated to streaming should be implemented in userspace as mush as possible because the driver doesn't reuire them. > Furthermore, the current state cannot be read back from the device, so > something in the computer must effectively cache it for the lifetime of the > device. Since the kernel driver will have this lifetime scope and requires > some of this information itself it's pretty much going to have to be that. M-Audio Firewire 1814/ProjectMix has a similar situation. They have write-only parameters and some of these parameters related to streaming. See: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/firewire/bebob/bebob_maudio.c?id=3149ac489ff8dea0c305c7f97ac2a1b4ad54f5be But currently, rest of the parametes are configured from userspace. See: http://subversion.ffado.org/browser/trunk/libffado/src/bebob/maudio/special_mixer.cpp > This difficulty is overcome in FFADO through the utilisation of shared > memory between FFADO components, where the first one to start sets up the > shm and the last to exit destroys it. It's not ideal but does at least give > continuity of device state most of the time. I think it better that kernel module keeps the state and give a way for applications to get/set the state, then commit whole settings as one transaction, as long as the parameters are related to streaming. For the M-Audio case, I use ALSA control interface for the parameters. But in this RME case, many parameters are included in the three quadlets and a few of them relate to packet streaming directly. To reduce codes in kernel module, I think it better to give a way to get/set the value of quadlets rather than each parameters. > 1) Provide the details via a structure obtained from an ioctl. > > 2) Create a directory in either procfs or sysfs, with one file per > parameter. I believe sysfs is preferred for this sort of thing these > days. > > 3) Make the information available via a special device in /dev/. > > 4) Use mixer controls. It is possible to have controls that are not > actually shown in the mixer, and there are already mechanisms to lock > controls, and to notify other programs of changes. Clemens has already mentioned about mixer controls (= ALSA control interface). I think SNDRV_CTL_ELEM_TYPE_BYTES control is suitable for my idea. I note that this idea requires a userspace application to parse bytes to read and compose bytes to write. >> If I got any testers: >> 1.MIDI-only ALSA driver for RME >> It's simpler to implement than isochronous streaming. > > Even this will still need support for the full configuration state (granted, > the actual handling of the MIDI data should be easier than the audio case > though). At the very least the MIDI side of things is going to have to > cooperate with the audio streaming side. As a result, a fairly complete > plan for the later audio-related work is going to be needed before > proceeding with this. > >> 2.ALSA driver for MOTU >> My headache is control messages in isochronous packet... > > I'm not sure what you're referring to here. There is certainly device > status feedback provided via the iso packets (eg: controls which can be > altered by hardware on the front panels) - maybe this is what you're > talking about? Exactly. >> I have no actual devices so cannot do reverse-engineering, while I can write >> ALSA drivers. If I get your help, I can work for it. > > Conversely, would you be able to offer suggestions if I was to pick this up? > Having worked with these devices for 4 or so years I think any attempt to > write a driver for them without having the physical devices to test with is > going to be relatively difficult (they are nothing like AMDTP interfaces). Yes. (I also required physical devices to develop Fireworks/BeBoB drivers because these devices typicaclly have their own quirks...) Regards Takashi Sakamoto o-t...@sa... |