UsabilityImprovementIdeas

From the ALSA wiki

Some Usability Improvement Ideas

DMIX

It seems that DMIX can solve many of the current problems, mainly the issue that multiple applications can output sound simultaneously, maybe a user listening to ogg files while the SIP phone should have the possibility to ring the bell. Furthermore, DMIX/asoundrc makes it possible to order the cards user specific, maybe making an USB card the first - maybe the default - card.

Currently, setting up DMIX needs manual user interaction, at least copying an asoundrc template into the system.

One could add functionality to alsaconf to create an asoundrc, but alsaconf itself (which has done a great job during the past years) needs some refactoring.

Perhaps it would be a good idea to rewrite it some day, removing the ISA stuff and make it able to configure more than one card, configure USB cards and create an asoundrc. This new script could then be used by GUI frontends (GUI doesn't necessarily mean user friendly, BTW ;-) .

Mixer

On cheap onboard AC 97 cards, alsamixer offers all possibilities of the chip, even if the chip abilities are not available to the user because some elements of the chip simply have no connection to the outside world. But ALSA cannot know which ports are connected to the chassis. So perhaps the mixer settings could be made configurable, so a set of mixer definitions for some well known cards could be created. There are rumors that there are already plans about it, so maybe something will rise the next time ;-) .

MIDI device naming / Customizable names

Sometimes there appear names of MIDI devices in aconnect which aren't very intuitive, may it be a hardware or software port. How about to offer the user the possibility to name the devices as he likes. It would be cool if ALSA itself could do so instead of applications (like qjackctl does), so all MIDI programs could benefit from it instead of one particular program.

This way, it would also be possible that a user could name the devices of a multi port card to something more user specific, maybe in port 1 of an Edirol UM-550 as Masterkeyboard in, port 2 as Doepfer Controller in and port three Synth input for SysEx recording. Just an idea.

This also is valid for programs which register its MIDI port simply by a number, which is sometimes confusing in aconnect (linuxsampler is one of the examples). Maybe it'd be possible to allow the user to rename such software ports persistently.

Maybe udev can do this for us, but I'm not yet familiar with enough with udev and ALSA.

Audio device naming / Customizable names

A similar issue exists for audio ins and outs. Furthermore, via DMIX it is possible to reorder the cards; but the common user is not able to modify an asoundrc, so there could be a small script (see above about an alsaconf replacement).

Example: A notebook with an AC 97 chip which also offers a modem and an external 5.1 USB soundcard for watching DVD. ALSA orders them as

0 [I82801CAICH3   ]: ICH - Intel 82801CA-ICH3
1 [Modem          ]: ICH-MODEM - Intel 82801CA-ICH3 Modem
2 [Audio          ]: USB-Audio - USB Audio

Maybe the user prefers

1 [Audio          ]: USB-Audio - USB Audio
2 [I82801CAICH3   ]: ICH - Intel 82801CA-ICH3

The user perhaps doesn't want to see the modem as a card, and maybe the user prefers the numering starting at 1 instead of 0, or the user likes to see no numbering at all but simply the cards to appear in a certain order.

Audio capture

Still, it is difficult for the common user to set up a machine to have some audio input, may it be to simply record vinyl to the hard drive or even to use a headset for SIP telephone software. The lists are full of questions like »I can hear the input of the card through my speaker, but I cannot record anything«. Well, even if the user manages the struggle with the different soundservers and audio systems (and artsd being not in full duplex mode per default ;-) it's simply difficult to understand how to set the soundcard to record the audio input. Maybe some improvement ideas for this issue could be collected.

It would be cool if - for example - an audio recording application could offer all necessary controls for audio input. This means which card to use (internal, USB), which input to use (line in, mic in 1, mic in 2), adjust the input gain and a control to see if any audio data appears on one of the inputs. Perhaps ALSA could offer some functions which makes it easier for application programmers to achieve this.

Programmer's interface

If a programmer had the idea to write a small and simple audio application, maybe for recording some audio, he'll wonder which audio layer to use. Artsd/esound? Outdated. Gstreamer or MAS? Not yet spread enough. OSS direct access? An ugly design to access the device exclusively. ALSA direct access? Also an ugly design to access the device exclusively. ALSA Plugin? Cool, but not (yet) available on most systems. JACK? Not running on normal user's system.

Perhaps he could make the application aware of many audio systems, and perform some checks each time it starts up.

Furthermore, it could remember the last used audio system, and offer the ability to change these settings by the user, maybe using program preferences in GUI programs or allow the user to modify the config file.

A startup check could perform as follows:

Audio system as defined in the preferences available? Connect to it. If not, Jack available? Connect to it. If not, arts available? Connect to it. If not, esound available? Connect to it. If not, gstreamer available? Connect to it. If not, MAS available? Connect to it. If not, ALSA available? Connect to it. If not, OSS available? Connect to it. If not, produce an error message.

But an programmer wants to focus on his application's functionality instead of writing many plugins and check routines. Can we give potentional audio developers a good starting point? Perhaps by writing some sample code to do this? It's not that easy because it depends on the programming language the application programmer wants to use.

SEQ

ALSA has a tool called seq; unfortunately, it conflicts with an equally called utility to create a sequence of numbers, and it does not get built per default. Maybe renaming it to something like aseq would be cool.

Persistent port identifiers

Several applications (like MusE, Rosegarden etc.) try to redo all connections they knew during the last runtime. This is no problem for hardware devices as long as they always are recognized in the same order. But it's a problem with different applications, even worse if there are multiple instances of an application running at the same time. The MIDI port numbers are distributed dynamically during an application's start, starting at port 129. The next time an application starts it will get an other number, maybe 131. Therefore, a system is needed to give an hardware or application port a persistent ID on a system. Mayba ALSA could remember the port an application used at the first time it appeared and reserve this port for it.