[alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters

[stan]

Mitul Sen (misen) wrote:
> I am a newbie to ALSA and any help will be much appreciated.
>
> I have an application which sets up the signaling between an IP phone
> and my desktop and then sets up the audio path between the two. 
>
> On my desktop application, I am able to receive RTP packets from IP
> phone. I use an RTP stack to parse the data and after going through the
> RTP stack, I try to play back the audio using ALSA. When I use the ALSA
> code to play back (in real time) using sound card of my device, there is
> only noise, I cannot hear the audio that I speak into the IP phone.
> However, if I take the raw data coming from the RTP stack and write it
> to a file, I can play back the file successfully.
>
> Since my data from IP phone is G.711 encoded, I have set the sampling
> rate within ALSA to 8000. Also I am using one source (mono) and
> non-interleaved data option for preparing ALSA for playback. When I set
> the format to SND_PCM_FORMAT_MU_LAW, at runtime it lets me set that
> format ie. snd_pcm_hw_params_set_format (for SND_PCM_FORMAT_MU_LAW) is
> successful. However I get a runtime error while applying the hardware
> parameters using snd_pcm_hw_params(..) if the format set earlier is
> SND_PCM_FORMAT_MU_LAW. Using any other format like SND_PCM_FORMAT_U8 or
> SND_PCM_FORMAT_S8, lets me apply the hardware parameters but it gives
> the problem of the noise (no "audible" voice) that I described earlier.
>   
This sounds like there is a mismatch in the data.  Two suggestions.

Look at the code that implements SND_PCM_FORMAT_MU_LAW in alsa-lib
and make sure it is correct (or actually there and not a stub).  See if 
there is some
other parameter(s) you have to set in order for it to function.

Write the output being sent to alsa-lib to a file as you are sending it 
and compare it
to the raw data you have captured that plays OK.  You want it to be the 
same.  If it
isn't, that is your problem.  If it is, the problem is in the alsa-lib 
decoding for this case.
Obviously, the coding must work in some case, because you are playing the
raw data successfully.  Either the application or alsa is decoding it 
successfully.  Compare
the successful decoding process with the unsuccessful decoding process.