Re: [FFADO-devel] [RFC] libhinawa: a light-weight I/O library for status/transactions to ALSA FireWire devices

Re: [FFADO-devel] [RFC] libhinawa: a light-weight I/O library for status/transactions to ALSA FireWire devices

[Jonathan Woithe]

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

Re: [RFC] libhinawa: a light-weight I/O library for status/transactions to ALSA FireWire devices

[Takashi Sakamoto]

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

[RFC] libhinawa: gobject introspection library for ALSA/FireWire transaction

[Takashi Sakamoto]

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