Wed Jul 14 10:20:28 PDT 2004
First let me introduce myself:
Sr Computer Scientist
20+ yrs SW/HW development
Audio Rookie < 60 days
Intel based computer
Soundblaster 128 PCI
Linux Fedora Core 2
ALSA - Advanced Linux Sound Architecture
ALSA provides the audio and MIDI functionality to the Linux operating system
as of Fedora Core 2 and is the future of Linux (so I have been told)
I have read the documentation for Speex and installed speex on my platform.
Prior to attempting compression, my software captured audio, stored it,
retrieved it and could play it back. The ALSA aplay utility could also
replay the files that were stored. The next obvious step is compression.
I have yet to correlate the ASLA terminology with the terminology used
in the speex documentation, and this is probably my biggest problem.
With the speex API, I can create an executable, but when I run it,
speex_bits_write always returns 38 bytes no matter what I send it.
Here are some details of what I am doing, some questions I have,
and hopefully someone can point out what I am doing wrong.
The ALSA call to snd_pcm_hw_params_set_format is setting the sound
format to unsigned 8 bit SND_PCM_FORMAT_U8
Q - Do I have to use 16 bit for speex?
The ALSA call to snd_pcm_hw_params_set_rate_near is setting the
rate to 11025 hz, the lowest I have been successful with.
Q - how does this correlate to speex narrow and wide modes?
The ALSA call to snd_pcm_hw_params_set_channels is setting it to
a single channel (MONO)
The ALSA call to snd_pcm_hw_params_set_periods is setting this
to 2. Periods used to be called fragments.
The ALSA call to snd_pcm_hw_params_set_buffer_size is setting this
to the period size (8192) times the number of periods (2)
The ALSA call to snd_pcm_readi has been tried with the number of frames
set to 100, 160, 200, 2000. It puts the data read into an unsigned char
After capturing the data, I copy the unsigned char array into a float array
and follow the example code in sampleenc.c
speex_encode(state, floatbuf, &bits);
cbytes = speex_bits_write(&bits, comprbuf, BUFSIZE);
cbytes always returns 38 no matter what the frames are set to in the
ALSA snd_pcm_readi call.
I do know that valid sound in the unsigned char array returned from the
ALSA snd_pcm_readi call is less than 0x7A, and anything above 0x7A is
background noise or silence.
Q - is this inverted for speex?
More information about the Speex-dev