Jonathan Woithe
2014-09-30 01:49:19 UTC
Hi Takashi S
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"?
week or so.
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
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 whateverI/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.
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 nextis a first RFC for it. It's under development and I require your
comments about its APIs and structure ...
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 DICEnotification 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.
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