Ticket #50 (closed enhancement: fixed)
Sound Event API
| Reported by: | mickey@… | Owned by: | mickeyl |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | openmoko-libs | Version: | unspecified |
| Severity: | minor | Keywords: | |
| Cc: | buglog@…, marcandre.lureau@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
libmokocore needs a sound event API so that applications and panel applets can
easily produce sounds.
This should include vibration.
This should include a way to change the mapping from events to sounds.
Change History
comment:4 Changed 6 years ago by marcandre.lureau@…
What about libcanberra? (the idea would be to have different implementation, but
a common API across sound systems/platforms)
http://svn.0pointer.de/viewvc/trunk/canberra.h?root=libcanberra&view=markup
comment:5 Changed 6 years ago by mickey@…
Sounds good, since we are already deploy pulseaudio in the platform. However, it
looks like libcanberra is still far away, isn´t it?
comment:6 Changed 6 years ago by marcandre.lureau@…
That's true. But it's not a complex library, it could be quickly implemented for
the basic stuffs, IMHO.
Though the more I discuss and think about it, the more I think libcanberra is an
"event API" more than a "sound" API.
Since libnotify is sensibly well designed, and could be included in the GNOME
stack, I don't see why libcanberra should be pushed in that case.
What about openmoko? do you use libnotify? (maemo does)
Otherwise, we have to redesign libcanberra to focus on "sound" (ie having less
meta/info, and more control over the sound being played - optionnaly)
Alternatives:
http://www.khronos.org/opensles/
