Hi,
On Apr 8 2016 05:10, Martin Koegler wrote:
On Thu, Apr 07, 2016 at 03:23:01PM -0400, Adam Goode wrote:
Have you heard any objections?
Also, would you plan to do a 1.1.2 release soon after accepting this, to get this functionality out quickly?
Distributions already start to pick 1.1.1 up: https://build.opensuse.org/request/show/382608 https://build.opensuse.org/request/show/382611
I would object merging that patch, if there is no immediate patched 1.1.2 release available, as otherwise 1.1.1 with a different API will get used by the mass.
Let's be careful. I also consider about this issue for this week, but still have no good idea. Band-aid sometimes fixes issues, but in this case, it's not better.
The design of alsa-lib is based on backend modules splitted from frontend API to applications. When a new feature is introduced, we tend to change the frontend API directly, ignoring the series of backends. This is not good in a view of the design. When adding new features to frontend API and the feature is just handled to one backend module, how do we implement it to the others.
Well, I think this issue of sequencer APIs includes below issues lying on the whole alsa-lib: - How to pass information of unsupported feature to frontend APIs from backend of the backend modules (i.e. kernel/userspace interface or perhaps IPC peer such as PulseAudio). - Some frontend APIs are designed as an accessor to structure members of opaque pointer. How to notify the information of unsupported feature to applications via the APIs. - How to prevent applications from confusion comes from implementation difference between the backend modules.
I think alsa-lib still has no good framework to solve these, against its long history of 15 years... Or long history might bring this issue.
Of cource, if few persons have interests in these issues to keep a good shape or quick fixes are more important than API consistency, it's better to apply your band-aid.
Regards
Takashi Sakamoto