Info: ALSA differences between live and standard debian desktop install

[Nick Bailey <nick@n-ism.org>]

Just in case anybody else is having trouble with large audio latency
on Debian Live-Build platforms, could I proffer the following observation?

I am building a live usb key which contains copies of various audio
and music applications for emperical musicology. One of the simpler
ones is a physical model of a bowed string which uses ALSA for low-latency
audio output.

Building the application on a Debian Testing (wheezy) platform results
in the desired operation. Using the same binary on a live-build key results
in long (between 3 and 5 seconds!) latency between received MIDI events
and audio output being produced.

FIX:

The ALSA hardware parameters had been set like this:

8><---
snd_pcm_t * OutputDirect::openPcm(std::string pcmName, unsigned int periodSize, 
unsigned int rate) {

    snd_pcm_t *playbackHandle;

    if (snd_pcm_open (&playbackHandle, pcmName.c_str(), SND_PCM_STREAM_PLAYBACK,
 0) < 0) {
                std::cerr << "OutputDirect: Cannot open audio device " << pcmNam
e << std::endl;
                throw new UnableToOpenPCMException;
    }

    snd_pcm_hw_params_t *hardwareParams;
    snd_pcm_hw_params_alloca(&hardwareParams);
...
    snd_pcm_hw_params_set_periods(playbackHandle, hardwareParams, 1, 0);
    snd_pcm_hw_params_set_period_size(playbackHandle, hardwareParams, periodSize, 0);

...
    return(playbackHandle);
}
8><---

Inserting the following lines after setting the period size causes
the ALSA system on the live-build system to behave in the same way as
the ALSA system on the normal Debian install.

8><---
    snd_pcm_uframes_t bufsize = periodSize * 2;
    snd_pcm_hw_params_set_buffer_size_near(playbackHandle, hardwareParams, &bufsize);
8><---

I don't understand why this is the case, although obviously expressly
modifiying the pcm parameters to require real time operation (short buffer/
early output) would have been good practice in the first place. That said,
snd_pcm_sw_params_set_avail_min() had been called which should've done
the trick (as indeed it did on the standard installs). That function's
supposed to set the "wake up point" so that the sound eminates as soon
as the given number of frames is available.

I'm not suggesting anybody should spend time to fix such an ephemeral bug.
But in the end, it took me almost 4 hours to find (hard to fix a program which
already works!), so here's hoping this saves somebody else the bother :)
Other applications, including jackd ones, seem to work just fine.

Nick/.