Re: [alsa-devel] [FFADO-devel] [RFC] libhinawa: a light-weight I/O library for status/transactions to ALSA FireWire devices
Hi Takashi S
On Tue, Sep 23, 2014 at 08:39:34PM +0900, Takashi Sakamoto wrote:
For some reasons (I describe later), I start to develop a light-weight I/O library for status/transactions to ALSA FireWire devices. https://github.com/takaswie/libhinawa
This library gives ways to use ALSA FireWire driver functionality such as lock/unlock kernel streaming, EFW transaction. This is one of my solutions to some issues between ALSA/FFADO.
As I understand it, this library will be a thin wrapper around whatever kernel interface is used to communicate these details out to userspace (I think byte-type mixer controls are the preferred avenue at present). In principle I have no problem with this approach so long as it remains lightweight. The situation to avoid is the one we had with libraw1394; when the new stack came about the preferred way to interact with it switched back to the native kernel interface since (as I understand the situation) it was felt that libraw1394 didn't really provide a worthwhile API abstraction.
Out of interest, is there any signficance in the library's name "hinawa"?
I hope to merge this library into alsa-tools package in future, and this is a first RFC for it. It's under development and I require your comments about its APIs and structure ...
I will try to find some time to look at the current proposal in the next week or so.
Dice notification is an actual example. Dice based devices transfer notification to a specific address on host controller. The address space is exclusive resources on an system. For Dice notification, ALSA Dice driver gives a way to utilize it for applications As well as Fireworks situation, some userspace stuffs are needed to use this functionality.
For sure. One thing to keep in mind is that while this is an issue for DICE devices it may not apply to others. The library API should be structured to keep in mind that not all features will be needed across the board. We don't want to burden all subsequent firewire-audio streaming drivers with baggage which is only required for a small subset.
Regards jonathan
Hi Jonathan,
On Sep 30 2014 10:49, Jonathan Woithe wrote:
The situation to avoid is the one we had with libraw1394; when the new stack came about the preferred way to interact with it switched back to the native kernel interface since (as I understand the situation) it was felt that libraw1394 didn't really provide a worthwhile API abstraction.
I'm sorry but I don't understand what you assume. What is 'the new stack'?
Out of interest, is there any signficance in the library's name "hinawa"?
I require unique name for this shared library. Then, for this RFC, I select 'hinawa' as surely-unique name, from Japanese word according to my association from 'FireWire'. ('hi' = 'fire', 'nawa' = 'wire').
The 'hinawa' is just my convinience. I don't mind to use another word for its name.
Dice notification is an actual example. Dice based devices transfer notification to a specific address on host controller. The address space is exclusive resources on an system. For Dice notification, ALSA Dice driver gives a way to utilize it for applications As well as Fireworks situation, some userspace stuffs are needed to use this functionality.
For sure. One thing to keep in mind is that while this is an issue for DICE devices it may not apply to others. The library API should be structured to keep in mind that not all features will be needed across the board. We don't want to burden all subsequent firewire-audio streaming drivers with baggage which is only required for a small subset.
My intention of this library is to write applications for device control with LL (however currently it's C only...). I have no plan to add other functionalities except for helping transactions and notification because I want to reduce my maintaining effort.
In short, I have no will to make alternatives of libraw1394, libiec61883, libavc1394 and libffado.
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp
Hi,
I re-write this library with libglib-2.0/libgobject-2.0. Currently it can be parsed by gobject introspection scanner and be available by gobject instrospection binding. In this time, I added python scripts as a test of combination between libhinawa and any GUI such as Gtk+, Qt.
https://github.com/takaswie/libhinawa
I'm happy to receive your comments.
== Background The most of FireWire sound devices require software implementation to control the device's functionality, such as 'matrix mixer' (See 3.2 Signal processing for internal mixing in https://github.com/takaswie/alsa-firewire-report). Currently FFADO project releases ffado-dbus-server/ffado-mixer for this role.
ALSA in Linux 3.16 or later support some FireWire sound devices newly, approximately 100 models or more. ALSA drivers give some functionality which FFADO doesn't support, such as Echo Fireworks Transaction and Dice Notification.
The aim of this library is to give a way to use these functionality. Furthermore, this library also supports read/write/lock transactions via Linux FireWire subsystem to help programmers.
== Language bindings via gobject introspection GObject introspection is a middleware layer between C libraries (using GObject) and language bindings. In short, libhinawa can be available by any languages which has gobject introspection support. https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
I re-designed libhinawa to use this mechanism. It becomes to depend libglib-2.0 and libgobject-2.0 additionally. It means to become a bit heavy to load these large library.
This library is still under development. API or object structure may be changed when they're required.
Regards
Takashi Sakamoto
participants (2)
-
Jonathan Woithe -
Takashi Sakamoto