Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-21 Thread Fabian Greffrath
Hi Thorsten et al.,

Thorsten Glaser wrote:
> I’d be happy to add an /usr/share/sounds/sf2/default.sf2 alternative
> to musescore-general-soundfont-lossless (which is about half a GiB
> already and expected to grow). Please note the changed location, as
> /usr/share/sounds/ is where soundfonts in Debian are expected to be
> packaged, and we’ve been subdirectory’ing them by format.

I am fine with any location for the default.sf2 file but agree with you
that we should stay consistent with the present packaging behaviour.

> Do we also wish a /usr/share/sounds/sf3/default.sf3 ? I’ve got four

I don't have a strong opinion about this. My concern is merely that we
have at least one soundfont installed so users can play MIDI
out-of-the-box. We can still decide wether to extend this to other formats
once we've got an implementation for SF2 alternatives working.

> On the other hand, putting them into /usr/share/sounds/sf?/ would
> make the programs pick them up in soundfont listings, so perhaps
> the different location (or just /usr/share/sounds/default.sf{2,3})
> might make sense?

I don't see a problem with a soundfont appearing twice, once under its
original filename and once as "default.sf2". Quite the contrary, I think
we should not "hide" it from users, it should be clear that there are
several soundfonts available and one of them is declared the default.

> Should we also make all packages providing an alternative for this
> Provides some virtual package, for others to depend on? I’d suggest
> sf2-soundfont and sf3-soundfont for naming, and SF3 soundfonts can
> Provides both of them.

Either this, or we could even introduce a real package that depends on one
of the providers and itself provides the named symlink and the
alternatives invocation in its maintainer scripts.

> Alternatives priorities could also be tricky. They can even differ
> between default.sf2 and default.sf3…

I believe that if you install a several-hundred-MB soundfont package you
did this for a reason and apparently want to use this soundfont as your
new default. So, as a rough measure, we could probably start with
timgm6mb-soundfont and increase priority with increasing package size.

> This might be tricky. Would uses rather have no sound (e.g. if we
> require GM) [or more soundfonts installed] or bad sound (e.g. if we
> don’t require GM, and, say fluid-soundfont-gs is the only installed)?

The point is that playing MIDI should immediately work out-of-the-box with
at least fluidsynth and gstreamer if one of the packages providing the
alternative is installed. So, I guess any SF2 soundfont providing a GM set
should be sufficient?

> Another point to think of: admins can locally install any¹ other
> soundfont by just copying it into place, and those can also serve
> as default soundfonts. This offers two questions:

In Debian, we can really only take care of other software that is in
Debian. However, we can make it as easy as possible to use Debian's
mechanisms for software not packaged, c.f. game-data-packager.

> • how easy is it for non-packaged things to be added to the
>   Debian alternatives system? I think it’s just one command,
>   which we could document in the consumers of soundfonts’ readmes.

It should be just one command, indeed, and we could document it somewhere,
e.g. in the Wiki. However, this already exceeds the "it should just work"
use case. If you care enough to install your own soundfont then probably
it can be expected that (a) you either already figured out how to tell
your MIDI rendering software how to use it or (b) you are able to nuke the
alternatives symlink and point a new one to your favourite soundfont
instead.

Thanks for your input!

 - Fabian



Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-20 Thread Thorsten Glaser
Hi Fabian and others,

>I believe we have at least three soundfonts in SF2 format packaged in
>Debian. If we add these to the alternatives system to provide
>/usr/share/soundfonts/default.sf2, the effort would be manageable.

I’d be happy to add an /usr/share/sounds/sf2/default.sf2 alternative
to musescore-general-soundfont-lossless (which is about half a GiB
already and expected to grow). Please note the changed location, as
/usr/share/sounds/ is where soundfonts in Debian are expected to be
packaged, and we’ve been subdirectory’ing them by format.

Do we also wish a /usr/share/sounds/sf3/default.sf3 ? I’ve got four
providers for this…
- fluidr3mono-gm-soundfont (no longer updated)
- musescore-general-soundfont-small (actively developed)
- musescore-general-soundfont (actively developed)
- musescore-general-soundfont-lossless (see below)

Note that all SF2 soundfonts could also provide default.sf3, it’s
about the player capabilities which to choose.

On the other hand, putting them into /usr/share/sounds/sf?/ would
make the programs pick them up in soundfont listings, so perhaps
the different location (or just /usr/share/sounds/default.sf{2,3})
might make sense?

Should we also make all packages providing an alternative for this
Provides some virtual package, for others to depend on? I’d suggest
sf2-soundfont and sf3-soundfont for naming, and SF3 soundfonts can
Provides both of them.

Alternatives priorities could also be tricky. They can even differ
between default.sf2 and default.sf3…

As for SFZ soundfonts, I’m not aware of any already packaged, but
MuseScore lists stuff in /usr/share/sounds/sfz/ already, if extant.

Oh, and, one more question: what soundfonts are eligible?

• any honouring the SoundFont 2.00 (2.01, 2.04) standard
  (for SF3: with Vorbis sample compression)
• + the GS set
• + the GM set

This might be tricky. Would uses rather have no sound (e.g. if we
require GM) [or more soundfonts installed] or bad sound (e.g. if we
don’t require GM, and, say fluid-soundfont-gs is the only installed)?

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-20 Thread Fabian Greffrath
Hi Tim, hi slomo, hi Thorsten,

On Sat, 18 May 2019 20:34:57 +0100 Tim Colgate  wrote:
> Unfortunately there doesn't seem to be a standard way in Linux of
setting a default soundfont to be used by all midi players; I was
wondering if it would be possible to use e.g. the /etc/alterntives
mechanism to choose between various Debian soundfonts e.g.
MuseScore_General_Full.sf2 and FluidR3_GM.sf2, and then modify the
gstreamer plugin to use that instead.

we are facing a similar issue in fluidsynth [1], i.e. the library is
looking for a default fall-back soundfont that is hard-coded as
/usr/share/soundfonts/default.sf2, but there is no package in Debian
providing that file.

I believe we have at least three soundfonts in SF2 format packaged in
Debian. If we add these to the alternatives system to provide
/usr/share/soundfonts/default.sf2, the effort would be manageable.
Then, we would have to adjust gstreamer to prefer this file before
falling back to searching through random directories. Could we agree to
do this after the next stable release, please?

Cheers,

 - Fabian


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929185


signature.asc
Description: This is a digitally signed message part


Bug#929185: gstreamer1.0-plugins-bad: no midi sound - gstreamer selects wrong soundfont by default

2019-05-18 Thread Tim Colgate
Package: gstreamer1.0-plugins-bad
Version: 1.14.4-1+b1
Severity: wishlist
Tags: upstream

Dear Maintainer,

I've been trying to get gstreamer to play midi files. Initially it was when 
using QMediaPlayer in a QT application. However it also applies when running 
gstreamer from the commandline, e.g.

gst-play-1.0 sample.mid

I can get it to work if I either specifiy the soundfount manually:

gst-launch-1.0 filesrc location=sample.mid ! midiparse ! fluiddec 
soundfont=/usr/share/sounds/sf2/MuseScore_General_Full.sf2 ! pulsesink

or I can also get the simple case of gst-play-1.0 to work if I remove all the 
soundfounts from /usr/share/sounds/sf2 except the one I want to use; 
unfortunately it was trying to use FluidR3_GS.sf2, which gives no sound.

The problem lies in libgstfluidsynthmidi.so; looking at the source code in 
ext/fluidsynth/gstfluiddec.c:gst_fluid_dec_open(), it tries to open a bunch of 
directories and then reads the first file in the first directory it can open 
(/usr/share/sounds/sf2).

I was hoping that there might be some kind of config file for gstreamer where I 
could set the default soundfont but I couldn't find one.

Unfortunately there doesn't seem to be a standard way in Linux of setting a 
default soundfont to be used by all midi players; I was wondering if it would 
be possible to use e.g. the /etc/alterntives mechanism to choose between 
various Debian soundfonts e.g. MuseScore_General_Full.sf2 and FluidR3_GM.sf2, 
and then modify the gstreamer plugin to use that instead.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gstreamer1.0-plugins-bad depends on:
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  libass9 1:0.14.0-1
ii  libbs2b03.1.0+dfsg-2.2
ii  libbz2-1.0  1.0.6-9
ii  libc6   2.28-5
ii  libcairo2   1.16.0-4
ii  libchromaprint1 1.4.3-1
ii  libcurl3-gnutls 7.58.0-2
ii  libdc1394-222.2.5-1
ii  libdca0 0.0.5-10
ii  libde265-0  1.0.2-2+b2
ii  libdrm2 2.4.97-1
ii  libdvdnav4  6.0.0-1
ii  libdvdread4 6.0.0-1
ii  libfaad22.8.8-1
ii  libflite1   2.1-release-1
ii  libfluidsynth1  1.1.11-1
ii  libgcc1 1:8.2.0-20
ii  libglib2.0-02.58.3-1
ii  libgme0 0.6.2-1
ii  libgsm1 1.0.18-1
ii  libgstreamer-gl1.0-01.14.4-1
ii  libgstreamer-plugins-bad1.0-0   1.14.4-1+b1
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libgudev-1.0-0  232-2
ii  libilmbase232.2.1-2
ii  libkate10.4.1-8
ii  liblcms2-2  2.9-1
ii  liblilv-0-0 0.24.2~dfsg0-1
ii  libmjpegutils-2.1-0 1:2.1.0+debian-5
ii  libmms0 0.6.4-2
ii  libmodplug1 1:0.8.9.0-1
ii  libmpcdec6  2:0.1~r495-1+b1
ii  libmpeg2encpp-2.1-0 1:2.1.0+debian-5
ii  libmplex2-2.1-0 1:2.1.0+debian-5
ii  libnettle6  3.4.1~rc1-1
ii  libnice10   0.1.14-1
ii  libofa0 0.9.3-15
ii  libopenal1  1:1.19.1-1
ii  libopenexr232.2.1-4
ii  libopenjp2-72.3.0-1
ii  libopenmpt0 0.3.6-1
ii  libopus01.2.1-1
ii  liborc-0.4-01:0.4.28-1
ii  libpango-1.0-0  1.42.0-1
ii  libpangocairo-1.0-0 1.42.0-1
ii  librsvg2-2  2.40.20-2
ii  librtmp12.4+20151223.gitfa8646d.1-1+b1
ii  libsbc1 1.3-2
ii  libsndfile1 1.0.28-4
ii  libsoundtouch1  2.1.2+ds1-1
ii  libspandsp2 0.0.6+dfsg-0.1
ii  libsrtp2-1  2.1.0-1
ii  libssl1.1   1.1.1a-1
ii  libstdc++6  8.2.0-20
ii  libusb-1.0-02:1.0.22-2
ii  libvo-aacenc0   0.1.3-1+b1
ii  libvo-amrwbenc0 0.1.3-1+b1
ii  libvulkan1  1.1.97-2
ii  libwayland-client0  1.16.0-1
ii  libwebp60.6.1-2
ii  libwebrtc-audio-processing1 0.3-1
ii  libwildmidi20.4.2-1
ii  libx11-62:1.6.7-1
ii