#mer-meeting: Sailfish OS, open source, collaboration – 12th December 2019

Meeting started by abranson at 09:02:50 UTC (full logs).

Meeting summary

    1. http://merproject.org/meetings/mer-meeting/2019/mer-meeting.2019-12-12-09.02.log.txt (ViGe, 09:04:53)
    2. Meeting information and agenda can be found here: (abranson, 09:05:28)
    3. https://lists.sailfishos.org/pipermail/devel/2019-December/008965.html (abranson, 09:05:28)

  2. Brief introduction (5 min). Please prefix your name/handle with # info (abranson, 09:06:28)
    1. Alexander Akulich - Telepathy developer (Kaffeine, 09:07:09)
    2. Ville Nummela - sailor@jolla (ViGe, 09:07:17)
    3. Nico - community member (Nico[m], 09:07:24)
    4. David Llewellyn-Jones - sailor @ Jolla (flypig, 09:07:47)
    5. Leif-Jöran Olsson, community (ljo, 09:07:50)
    6. Andrew Branson - sailor at Jolla and first time chair! (abranson, 09:07:53)
    7. Vincent Knecht - community (vknecht, 09:08:09)
    8. Martin Kolman - community member & modRana developer (M4rtinK, 09:08:14)
    9. Damien Caliste, community (read-only today :) (dcaliste, 09:08:29)

  3. Introduce (some more) packaging conventions (Asked by Kaffeine - 10 mins) (abranson, 09:12:34)
    1. we have a lot of layouts and approaches in (external, not MER) projects packaging. To name a few, we have: 1. "rpm dir + 'upstream' git submodule", 2. "rpm + upstream submodule + a dir with extracted and patched sources", 3. "spec + tarball" (not in OBS, but right in the packaging git repo), 4. "rpm + git subtree with applied patches", 5... . (abranson, 09:12:50)
    2. As far as I understand, the modern approach is to have "rpm + <package-name> directory with git submodule". I would like this approach to be approved and documented. Just a few lines on a page in Sailfish wiki will prevent the further disorder and let other developers help you to clean up the current packaging stuff (abranson, 09:12:50)
    3. These packaging formats are described in detail on the wiki https://sailfishos.org/wiki/Building_packages#Packaging_formats (abranson, 09:16:02)
    4. Repo with rpm folder (with few patches if needed) with package named submodule is the preferred way if there are not many changes to the submodule code. (abranson, 09:16:02)
    5. If there are a lot of changes to the upstream code then a submodule+patches might become quite complicated to maintain so then the third option mentioned in the link above with a upstream submodule and a package named folder with whole source in the repo might be more convenient. (abranson, 09:16:02)
    6. The selected option of course depends on whether the upstream sources are available in a git repository, if not then a copy of the sources in git is needed. Use of the obsolete spec+tarball format should not be used. (abranson, 09:16:11)
    7. ACTION: Look at summarizing the format criteria on the wiki page to make things clearer for community devs (abranson, 09:26:09)

  4. Bad audio quality on Xperia X and Jolla phone (Asked by Nico[m] - 10 mins) (abranson, 09:26:28)
  5. Bad audio quality on Xperia X and Jolla phone (Asked by Nico[m] - 10 mins) (abranson, 09:26:44)
    1. some details about the topic: I listen to a lot of music on the go. One thing that always bothered me, is that the audio quality in Sailfish seems a lot worse than when using Android or even my Nokia N9 (iirc). There seems to be a consistent noise floor, when using high quality head phones. (abranson, 09:26:44)
    2. More info: https://together.jolla.com/question/169231/poor-audio-quality-sailfish-x-jolla-1/ I would really appreciate it, if there would be some way to fix that, as it seems to be an issue with the way SailfishOS handles the hardware, not in the software decoding, etc. (abranson, 09:26:45)
    3. Part of the answer is in this tjc reply: https://together.jolla.com/question/169231/poor-audio-quality-sailfish-x-jolla-1/ mainly the part about The root of the problem is that somehow the volume control only scales the waveform in software, while the final amplifier is always at maximum volume. This is "feature" in normal audio use cases, it's just how the audio adaptation is implemented in Android. However, there are (abranson, 09:29:51)
    4. The thing is, we haven't implemented any offload playback, due to it being quite complicated thing to do. Mainly because of so many places it requires work on, first PulseAudio doesn't bend so easily to passthrough playback (there exists already passthrough playback but it's targeted for spdif or like, it was encapsulated with some thingamaboob I don't remeber right now, so something needs to be done to handle wav or (abranson, 09:30:03)
    5. Second part of the answer is, right now we use pretty much whatever the adaptation says it has, and we may or may not misuse it slightly as we cannot use the interface 1:1 how audioflinger does. It very well may be that we don't have some ACDB or other switch in correct state as many adaptations have additional parameters which are seemingly not needed but "do things". (abranson, 09:30:13)

  6. General discussion (20 min) (abranson, 09:36:33)
    1. https://git.sailfishos.org/mer-core/nemo-qtmultimedia-plugins/merge_requests/2 (abranson, 10:03:09)

  7. Next meeting time and date (5 min) (abranson, 10:13:20)
    1. Next meeting will be held on Thursday 9th January 2020 at 09:00 UTC (abranson, 10:18:26)


Meeting ended at 10:19:16 UTC (full logs).

Action items

  1. Look at summarizing the format criteria on the wiki page to make things clearer for community devs


People present (lines said)

  1. abranson (65)
  2. Nico[m] (26)
  3. r0kk3rz (16)
  4. vknecht (15)
  5. M4rtinK (11)
  6. Kaffeine (10)
  7. ViGe (7)
  8. Venemo (7)
  9. merbot` (3)
  10. flypig (3)
  11. jusa (3)
  12. FireFly (2)
  13. ljo (2)
  14. TheKit[m] (2)
  15. dcaliste (1)
  16. pvuorela (1)


Generated by MeetBot 0.1.4.