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