| Summary: | add new audio backend for sndio | ||
|---|---|---|---|
| Product: | swfdec | Reporter: | Jacob Meuser <jakemsr> |
| Component: | library | Assignee: | swfdec ml <swfdec> |
| Status: | ASSIGNED --- | QA Contact: | swfdec ml <swfdec> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OpenBSD | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | two patches and a source file | ||
|
Description
Jacob Meuser
2009-03-08 03:08:59 UTC
Created attachment 23652 [details]
two patches and a source file
From reading the code (as I cannot test it), the patch looks fine. I don't want to add this to the Swfdec 0.8 branch, as patches there should be as small as possible and not include new features (I've been getting questions from distros about every patch). So I suggest you keep it as a custom patch in the OpenBSD ports system. I'm however not really sure how I want to handle audio backends in Swfdec after the experiences I've had with OSS and Pulse. For everyone reading this, the short version of the problem is: a) There are no core Swfdec developers using the specific backend, so it is not exposed to the same amount of testing. b) People download Swfdec and compile it with their preferred audio backend. When using it, it crashes, so they conclude Swfdec sucks and don't bother again. I don't want to lose users (or even distros, as those users in b) have been distro packagers) just because they don't know that the audio backends have different levels of support and assume the experience with their chosen audio backend is an indication of overall Swfdec quality. On the other hand it's a good idea to support as many audio backends as possible. So I'm torn between adding audio backends and suggesting that distros maintain their own backend. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.