New sound theme proposal for the 6.04 release

[Ivica Ico Bukvic]

> It would be fantastic to form a team around this. Ivica, would you
> consider doing that? I'm absolutely open to a new sound theme for
> Dapper, we have wanted to do something great with sounds for Hoary and
> Breezy and not had any strong contributions yet. So this is a good area
> to contribute if you have the skills.

I would love to contribute. I have been involved in Linux, more particularly
in the Linux Audio Developers group for the past 7 years and have been using
Linux as the multimedia platform of choice since (although to be honest not
exclusively). FWIW, I am also currently serving as the director of the
Linuxaudio.org consortium (speaking of which, I should talk to you at some
point regarding possibly having Ubuntu project become a member of the
consortium).

> 
> I like the idea of a theme that is not intrusive. It's a reasonable
> criticism of Ubuntu to say that its "noisy", it does tend to talk quite
> a lot, and the sounds are not polished nor are they consistent. I would
> love a sound scheme which is in keeping with the Human theme - warm,
> polished sounds.
> 
> Some other thoughts:
> 
>   - Kubuntu would also benefit from this work. I don't know to what
> extent they would want to harmonise the sound themes - KDE has quite a
> different "feel" to Gnome and so a different sound theme may be a
> requirement there.

I agree. The two desktops do have a "different feel," as you have put it.
And for this reason I do agree that the two desktops should perhaps have a
different startup/logout sounds. However, IMHO the apps whose function is
similar would probably benefit from the use of the same sounds. For
instance, the "incoming email" event for apps such as Evolution and Kmail,
would benefit from a clear consistent sound as this would help users (should
they desire to do so) to seamlessly switch from one desktop to another
without necessarily loosing the valuable psychoacoustic associations that
have been generated by the consistent exposure to the same sonic event.

> 
>   - I would like to see deep work done on the actual apps. Get the same
> sound going for a new private conversation in BOTH Gaim and X-chat AND
> the KDE IM app. Get the same sound for a new email message on Evolution
> AND Thunderbird AND the KDE equivalent (though KDE might need to be
> different, see above).

Absolutely agree. Would some of the following examples work?

http://meowing.ccm.uc.edu/~ico/Linux/Kmail.ogg (incoming e-mail)

http://meowing.ccm.uc.edu/~ico/Linux/Kopete_notify.ogg (kopete notification)
http://meowing.ccm.uc.edu/~ico/Linux/Kopete_status.ogg (kopete status)
http://meowing.ccm.uc.edu/~ico/Linux/Kopete_offline.ogg (kopete offline)
http://meowing.ccm.uc.edu/~ico/Linux/Kopete_send.ogg (kopete send message)
http://meowing.ccm.uc.edu/~ico/Linux/Knock.ogg (kopete somebody's online)

(these could likely also apply to Gaim and/or X-chat which would again
reinforce the idea of having the same sound associated with similar actions
even if they come from different apps, I just need to investigate their
sound events to see which ones would be required in addition to these)

http://meowing.ccm.uc.edu/~ico/Linux/Popup.ogg (simple desktop popup)
http://meowing.ccm.uc.edu/~ico/Linux/Question.ogg (desktop question)

> 
>   - The ESD framework we currently use for sound seems to have issues
> with syncronization (as does the KDE one). Is there anything we can do
> to improve that? Make it so clicking results in a sound, not a pause and
> then a belated click sound?

My suggestion (FWIW) would be dropping esd in favor of ALSA's dmix plugin
(although I am not sure whether Gnome can talk directly to ALSA layer
without having an interim sound server/sink mechanism).

The latency you are encountering is due to the fact that both the esd and
aRtsd by default use huge internal buffer that allows for low CPU overhead
(this being more of a concern on the old machines when these technologies
had first come into existence). Due to this internal buffer you get to
perceive the nasty delay and all other kinds of inadequacies. More
importantly, due to their deprecated design, neither is compatible with each
other.

In KDE you can *minimize* this problem by going into the Sound Server
Settings and lowering the buffer length. Naturally, at some point without
the realtime privileges you will encounter dropped samples but there are
ways around this too (i.e. realtime-lsm module plus the realtime option in
the Sound Server settings). All this being said, last I heard KDE devs are
working on a major overhaul of the audio architecture for the 4.x release,
possibly adopting the gstreamer, which would greatly minimize cross-desktop
(in)consistency headaches.

The aforementioned Alsa dmix plugin comes with the Alsa lib package and is
enabled by default. All the magic happens in the /etc/asoundrc file (users
can furthermore overwrite the system settings in their own $HOME/.asoundrc
files). The dmix plugin namely provides ability for multiple processes to
concurrently access the soundcard. Alsa layer takes care of the rest. The
utilization of this solution would have to depend on some kind of a database
as some of the soundcards do provide hardware sound mixing ability (although
they are more of an exception than a rule, such as the audigy/sb live!
series) and therefore at least theoretically do not require neither the esd
nor the dmix.

Similar to the aforementioned "dmix," there is also the "snoop" plugin which
does exactly the same thing for the audio capturing. The two plugins can be
then combined to generate a meta-soundcard that would for all intents and
purposes work seamlessly with multiple apps. ALSA should be able to also do
the same for the old OSS-based audio apps by providing the /dev/dsp
emulation layer that is routed to the same sink. Granted, even this solution
will require some pre-buffering which can be adjusted in the aforementioned
asoundrc file, but at least this way you would get a desktop-independent
solution. In addition, pro-audio users could still access the card directly
using JACK (which most of us do anyways) therefore bypassing the extra
layer.

Finally, there is also the pro-audio wonder called JACK but for a casual
day-to-day use it may prove to be an overkill. Both aRtsd and gstreamer,
however, do supposedly have the ability to talk directly to the JACK server
and I heard the rumors that Linspire at one point tried to go all-JACK on
their distribution (not sure if this ever came to fruition, though). JACK
has the advantage of routing audio between the apps as well as sharing the
audio I/O. More importantly, JACK does this in a sample-accurate fashion
which again will seem like an overkill for a casual use, but does wonders
for the pro-audio needs. Finally, Alsa does provide jackplug plugin which
can also allow alsa apps that are not JACK-aware to be piped into JACK
asynchronously. There are at least 4 other projects that do similar thing,
such as libjackasyn (a.k.a. jacklaunch), oss2jack, and others, all of which
act very similarly to esd (and/or asd and other similar hacks). They are
IMHO a mixed bag but can prove to be a good interim solution should you guys
decide to go with JACK.

Hope this helps!

Best wishes,

Ico