[Feedback] DBus Interface Needed Enhancements

[Ian Monroe]

On 8/12/07, Miguel Angel Alvarez <maacruz at gmail.com> wrote:
> Hi all,
> I want to add my little grain of sand to the ongoing dicussion (Who is me? See
> replaygain plugin)
> I don't know how the new dbus interface will be, so I can't talk about it, but
> I know the current interface.
> I usually don't like the idea of breaking backwards compatibility and big
> api/interface changes, unless it is absolutely needed (if it works, don't fix
> it). Having said that, in this particular case, the new dbus interface is, by
> itself, a complete departure from dcop, so it could be a good oportunity to
> change whatever needs to be changed, but no need to throw away the current
> system.

Makes sense.

> The current script interface allows quite a number of things, and in some
> aspects it is very complete, but in other aspects it is severely lacking.
> I think the actual number of dcop calls is mostly very complete. Almost every
> aspect can be controlled with a dcop call. Also, the notifications method is
> very simple, making very easy to write plugins.
> The notifications are very scarce. There are quite a number of events the
> scripts can only know by polling with dcop calls (for example, user driven
> track changes, playing mode changes, configuration change...), which is not
> good, and still worse, there are some events that the scripts have no
> absolutely way to know about (for example, database events). This limits
> greatly what plugins can do or what plugins can be written.
> Notifications should be providen for any event which causes a  change in
> amarok state or behaviour.

DBus has a proper signal system, so thats helpful.

> The database could see some small improvements: some simplified query
> mechanism, some way to add fields to save plugins related information...

The database should not be designed with script writers in mind. It's
impossible for us to guarantee that there won't be changes. But we
should make the 'query' call an absolute last resort, and instead have
a DBus interface to do all the sorts of things that query is currently
being used for.

> Another problem is response time.  In some cases a great problem, indeed. This
> time can be in the order of seconds! in extreme cases. Obiously, this greatly
> hurts interactivity and coupling (for my plugin that's a major problem). This
> should be corrected.
> Related to this, many things happens at trackchange time, and some of them
> have high cpu load, while it is not important that they are highly
> sinchronous with the track change (like cover art and context pane
> rendering).
> So, to avoid such concentrated load, I suggest launching such tasks some small
> time (like 0,1 or 0,5 seconds) after track change in their own low priority
> thread. May be, plugins could request high priority to get some preferential
> treatment?
>
> Other thing people complain about, is the lack of sound processing plugins. I
> think that support could be (easily?) added for such plugins by providing a
> way access the wave bytestream, just before it is sent to /dev/pcm, by using
> pipes or sysv shared memory. Just imagine the whole new world of posibilities
> this would open... sound normalization, filters, effects ....
> Could it be done?

Amarok still doesn't do anything with stuff like /dev/pcm but relies
on Xine. Phonon does have an effects system, but I don't know whether
something like sound normalization could be done with it.

> As a final suggestion, may be we should start a wiki page about this?

I agree. I think the script writers would be the ideal folks to design
a new DBus API. Implementing the API would be a good junior job, the
next time someone says they want to work on Amarok we could just point
them to the wiki page.

Designing the API will be a challenge, as there are lots of features
that have to be retained. And how to do some things like provide a
good way to interface with the database isn't at all obvious.

Also there is this proposed standard for Media Player DBus Interfaces:
http://wiki.xmms2.xmms.se/index.php/Media_Player_Interfaces

Might use it as a starting point. Having "MPRIS" compatibility would be nice.

Ian Monroe