Re: [bongo-devel] Re: Add TODO item: Implement support for crossfading

[Daniel Brockman]

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> address@hidden (Daniel Jensen) writes:
>>
>>> Crossfading requires mixing. Since Bongo does not decode files, we
>>> need external support. Unfortunately, I think it's hopeless finding
>>> good crossfading support in external players.
>>
>> I was thinking we could just start multiple external players
>> and adjust the volumes.
>
> Yes, that was my suggestion (I think).

Oh, okay, sorry.

> It won't work if the audio device does not support mixing.
> Correct me if I'm wrong.

Yes, that's right.

>>> That leaves audio mixing at the device level (e.g. ALSA).
>>
>> How?
>
> It used to be (and still is) that OSS on Linux did not handle mixing.
> People developed sound servers like ESD to implement mixing on top of
> the device. And ALSA finally introduced its own mixing.

Right, okay.

> Naturally, applications need to use the same system for mixing (which
> they don't). If you start playing something with ALSA, an OSS
> application will be blocked. This is very bad, and a program typically
> will exit if it can't open the sound device.

Yes, that is a problem (though not really Bongo's problem).

> There might be solutions for this. I'm not sure though,
> because this concludes what I know about sound mixing.

I never intended to attempt to solve the mixing problems
that you describe.  My idea was to implement crossfading by
assuming that the sound system can do the necessary mixing,
running multiple players at once, and changing their volumes.

Setting aside the mixing problem (which I don't think we
should attempt to fix --- people who can't play more than
one sound at once won't expect crossfading from Bongo),
the problem of changing player volumes remains.

There are commands in mplayer and VLC for changing the volume,
which is what made me believe we could implement this.

However, I found out that changing the volume through mplayer
actually just changes the volume of the output device itself.
As a consequence, if you start two mplayer processes, changing
the volume of one also changes the volume of the other.
The upshot is that mplayer cannot be used for crossfading.

I have not been able to investigate whether VLC has its own
internal gain stage.  When I tested VLC's remote control
volume commands (`volume', `volup' and `voldown'), I could
not seem to get them to do anything at all.

Maybe it's possible to tell VLC to add a gain stage, much like
one can tell mplayer to add various audio and video filters?
Maybe it's possible for mplayer?  Maybe for both of them?

By the way, I have been meaning to write a GStreamer backend.
I don't know what remote control facilities are available with
the standard GStreamer command line tools, however --- if any.

If anyone here knows GStreamer better than I do (and I know
nothing at all), you're welcome to take a shot at it.

In other news, RMS suggested we rip out the mplayer backend
code altogether, due to mplayer's many copyright problems.
He made the point that free media players ``is a major area of
weakness of will in our community, so strengthening the demand
for freedom in that area is important.''  Therefore, he thinks
we should support ``only players that are 100% free software.''

I cannot other than sympathize with that sentiment.  The fact
that it appears almost impossible to install mplayer in Debian
does indicate a ``weakness of will'' on the part of the mplayer
developers who won't sort out the copyright problems.

So to take a stand for software freedom, we should purposefully
not support mplayer by default.  In pracice, this means removing
the mplayer backend code from the main repository.  Maybe it can
find a new home on EmacsWiki.

Thoughts?  (Maybe CC replies to this part to <address@hidden>.)

-- 
Daniel Brockman <address@hidden>