* Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
@ 2008-06-30 22:09 Mitul Sen (misen)
2008-07-01 7:39 ` Clemens Ladisch
2008-07-01 13:59 ` stan
0 siblings, 2 replies; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-06-30 22:09 UTC (permalink / raw)
To: alsa-devel
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 is what my ALSA code looks like
***** beginning of code snippet *****************
int err;
snd_pcm_hw_params_t *hw_params;
// Try to open the default device
err = snd_pcm_open( &_soundDevice, "plughw:0,0",
SND_PCM_STREAM_PLAYBACK, 0 );
// Check for error on open.
if( err < 0 )
{
printf("Init: cannot open audio device\n");
return -1;
}
// Allocate the hardware parameter structure.
if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0)
{
printf("Init: cannot allocate hardware parameter structure\n");
return -1;
}
if ((err = snd_pcm_hw_params_any (_soundDevice, hw_params)) < 0)
{
printf("Init: cannot initialize hardware parameter structure\n");
return -1;
}
// Set access to RW interleaved.
if ((err = snd_pcm_hw_params_set_access (_soundDevice, hw_params,
SND_PCM_ACCESS_RW_NONINTERLEAVED)) < 0)
{
printf("Init: cannot set access type\n");
return -1;
}
if ((err = snd_pcm_hw_params_set_format (_soundDevice, hw_params,
SND_PCM_FORMAT_MU_LAW)) < 0)
{
return -1;
}
// Set channels to mono (1)
if ((err = snd_pcm_hw_params_set_channels (_soundDevice, hw_params, 1))
< 0)
{
return -1;
}
// Set sample rate.
unsigned int actualRate = 8000;
if ((err = snd_pcm_hw_params_set_rate_near (_soundDevice, hw_params,
&actualRate,
0)) < 0)
{
return -1;
}
// Apply the hardware parameters that we've set.
if ((err = snd_pcm_hw_params (_soundDevice, hw_params)) < 0)
{
printf("Audio device parameters have not been set
successfully.(%s)(%s)\n", strerror (err), snd_strerror (err));
return -1;
}
// Free the hardware parameters now that we're done with them.
snd_pcm_hw_params_free (hw_params);
/* Prepare interface for use.
if ((err = snd_pcm_prepare (_soundDevice)) < 0)
{
printf("Audio device not prepared for use\n");
return -1;
}
// If the frames are received...
/* find out how much space is available for playback data
if ((frames_to_deliver = snd_pcm_avail_update (_soundDevice)) < 0)
{
printf("Error returned by snd_pcm_avail_update\n");
}
frames_to_deliver = frames_to_deliver > 4096 ? 4096 : frames_to_deliver;
printf("frames to deliver is %d\n",(int)frames_to_deliver);
*/
frames_to_deliver = 172;
bufs[1] = (void*)buffer;
if ((err = snd_pcm_writen( _soundDevice, bufs, frames_to_deliver)) < 0)
{
printf ("write failed (%s)\n", snd_strerror (err));
}
****************** end of code snippet
**********************************
The error I get is as follows:-
Audio device parameters have not been set successfully.(Unknown error
4294967274)(Invalid argument)
Any pointers on what I could be doing wrong?
Thanks and regards,
Mitul
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-06-30 22:09 Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters Mitul Sen (misen)
@ 2008-07-01 7:39 ` Clemens Ladisch
2008-07-01 17:01 ` Mitul Sen (misen)
2008-07-01 13:59 ` stan
1 sibling, 1 reply; 15+ messages in thread
From: Clemens Ladisch @ 2008-07-01 7:39 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
> // Set access to RW interleaved.
> if ((err = snd_pcm_hw_params_set_access (_soundDevice, hw_params,
> SND_PCM_ACCESS_RW_NONINTERLEAVED)) < 0)
The comment and the code do not agree. Please try
SND_PCM_ACCESS_RW_INTERLEAVED.
Regards,
Clemens
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-06-30 22:09 Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters Mitul Sen (misen)
2008-07-01 7:39 ` Clemens Ladisch
@ 2008-07-01 13:59 ` stan
2008-07-01 18:42 ` Mitul Sen (misen)
1 sibling, 1 reply; 15+ messages in thread
From: stan @ 2008-07-01 13:59 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-01 7:39 ` Clemens Ladisch
@ 2008-07-01 17:01 ` Mitul Sen (misen)
0 siblings, 0 replies; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-01 17:01 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
The code is correct (as intended). I am sorry I forgot to change the
comment. I think I should be using SND_PCM_ACCESS_RW_NONINTERLEAVED
since I have only one source (mono). Please correct me if that is wrong.
Regards,
Mitul
-----Original Message-----
From: alsa-devel-bounces@alsa-project.org
[mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of Clemens
Ladisch
Sent: Tuesday, July 01, 2008 12:39 AM
To: Mitul Sen (misen)
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does
not let me apply hardware parameters
Mitul Sen (misen) wrote:
> // Set access to RW interleaved.
> if ((err = snd_pcm_hw_params_set_access (_soundDevice, hw_params,
> SND_PCM_ACCESS_RW_NONINTERLEAVED)) < 0)
The comment and the code do not agree. Please try
SND_PCM_ACCESS_RW_INTERLEAVED.
Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-01 13:59 ` stan
@ 2008-07-01 18:42 ` Mitul Sen (misen)
2008-07-01 22:12 ` stan
0 siblings, 1 reply; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-01 18:42 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
Thanks for your suggestions. For the first suggestion, how would I know the version of alsa-lib that I am using so that I can download the source code for the same? Is alsa-lib the same as libasound? Under /usr/lib/libasound.so I have a symbolic link to libasound.so.2.0.0. Is that then the version I should be looking for?
I am really new to this so please excuse me if these questions are too basic for this forum!
Thanks,
Mitul
-----Original Message-----
From: stan [mailto:ghjeold_i_mwee@cox.net]
Sent: Tue 7/1/2008 6:59 AM
To: Mitul Sen (misen)
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-01 18:42 ` Mitul Sen (misen)
@ 2008-07-01 22:12 ` stan
2008-07-01 23:50 ` Mitul Sen (misen)
0 siblings, 1 reply; 15+ messages in thread
From: stan @ 2008-07-01 22:12 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
>
> Thanks for your suggestions. For the first suggestion, how would I
> know the version of alsa-lib that I am using so that I can download
> the source code for the same? Is alsa-lib the same as libasound? Under
> /usr/lib/libasound.so I have a symbolic link to libasound.so.2.0.0. Is
> that then the version I should be looking for?
>
> I am really new to this so please excuse me if these questions are too
> basic for this forum!
>
> Thanks,
> Mitul
>
Good queston. I know because of the package. You can find the driver
version by running cat /proc/asound/version and the utilities
version by running aplay --version .
I couldn't find a way to get the library version. You can use the run
alsa-info.sh --no-upload and the output will have the driver,
library, and tool version at the top.
The script is found at http://www.alsa-project.org/alsa-info.sh
libasound is always version 2.0.0, no matter the alsa-lib version. I
presume that is to facilitate testing and upgrading. Nothing will break
with newer versions. So that is unrelated to alsa version.
You can find the latest beta versions of all the alsa source here
http://www.alsa-project.org/main/index.php/Changes_v1.0.17rc2_v1.0.17rc3
And a link to the latest stable release here
http://www.alsa-project.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-01 22:12 ` stan
@ 2008-07-01 23:50 ` Mitul Sen (misen)
2008-07-02 2:20 ` stan
0 siblings, 1 reply; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-01 23:50 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
Hi Stan,
Thanks for all your help! I have some more questions though...
I downloaded the source code for alsa-lib-1.0.15
Based on the code, if the format is SND_PCM_FORMAT_MU_LAW, I am not sure
why it does a get/put index to SND_PCM_FORMAT_S16 Also, if the stream is
SND_PCM_STREAM_PLAYBACK, then I would think that it should decode the
data. Why does it call snd_pcm_mulaw_decode function if the format is
SND_PCM_FORMAT_MU_LAW and snd_pcm_mulaw_encode otherwise. I have an
Intel HDA soundcard and according to the specs, it should support PCM
ulaw format.
All ALSA documentation and examples I have come across use specific
hw_params (like sample rate of 44100, SND_PCM_FORMAT_S16, 2 channel
interleaved data). According to the documents, hw_params refer to the
stream related info so that's the reason I tried to change it to that of
mu-law (sampling rate of 8000 Hz, SND_PCM_FORMAT_MU_LAW etc). Not sure
if that's the way to do it though. Based on the code it looks like the
hardware just seems to support SND_PCM_FORMAT_S16. Any pointers to help
me better understand the ALSA code would be much appreciated.
The code that I am referring to is in pcm_mulaw.c and is as follows:-
static int snd_pcm_mulaw_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *
params)
{
snd_pcm_mulaw_t *mulaw = pcm->private_data;
snd_pcm_format_t format;
int err = snd_pcm_hw_params_slave(pcm, params,
snd_pcm_mulaw_hw_refine_cchange,
snd_pcm_mulaw_hw_refine_sprepare,
snd_pcm_mulaw_hw_refine_schange,
snd_pcm_generic_hw_params);
if (err < 0)
return err;
err = INTERNAL(snd_pcm_hw_params_get_format)(params, &format);
if (err < 0)
return err;
if (pcm->stream == SND_PCM_STREAM_PLAYBACK) {
if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
mulaw->getput_idx =
snd_pcm_linear_get_index(format, SND_PCM_FORMAT_S16);
mulaw->func = snd_pcm_mulaw_encode;
} else {
mulaw->getput_idx =
snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, mulaw->sformat);
mulaw->func = snd_pcm_mulaw_decode;
}
} else {
if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
mulaw->getput_idx =
snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, format);
mulaw->func = snd_pcm_mulaw_decode;
} else {
mulaw->getput_idx =
snd_pcm_linear_get_index(mulaw->sformat, SND_PCM_FORMAT_S16);
mulaw->func = snd_pcm_mulaw_encode;
}
}
return 0;
}
Thanks and regards,
Mitul
-----Original Message-----
From: stan [mailto:ghjeold_i_mwee@cox.net]
Sent: Tuesday, July 01, 2008 3:12 PM
To: Mitul Sen (misen)
Cc: alsa-devel@alsa-project.org
Subject: Re: [alsa-devel] Setting format to SND_PCM_FORMAT_MU_LAW does
not let me apply hardware parameters
Mitul Sen (misen) wrote:
>
> Thanks for your suggestions. For the first suggestion, how would I
> know the version of alsa-lib that I am using so that I can download
> the source code for the same? Is alsa-lib the same as libasound? Under
> /usr/lib/libasound.so I have a symbolic link to libasound.so.2.0.0. Is
> that then the version I should be looking for?
>
> I am really new to this so please excuse me if these questions are too
> basic for this forum!
>
> Thanks,
> Mitul
>
Good queston. I know because of the package. You can find the driver
version by running cat /proc/asound/version and the utilities
version by running aplay --version .
I couldn't find a way to get the library version. You can use the run
alsa-info.sh --no-upload and the output will have the driver,
library, and tool version at the top.
The script is found at http://www.alsa-project.org/alsa-info.sh
libasound is always version 2.0.0, no matter the alsa-lib version. I
presume that is to facilitate testing and upgrading. Nothing will break
with newer versions. So that is unrelated to alsa version.
You can find the latest beta versions of all the alsa source here
http://www.alsa-project.org/main/index.php/Changes_v1.0.17rc2_v1.0.17rc3
And a link to the latest stable release here http://www.alsa-project.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-01 23:50 ` Mitul Sen (misen)
@ 2008-07-02 2:20 ` stan
2008-07-03 18:55 ` Mitul Sen (misen)
2008-07-16 23:36 ` Mitul Sen (misen)
0 siblings, 2 replies; 15+ messages in thread
From: stan @ 2008-07-02 2:20 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
> Hi Stan,
>
> Thanks for all your help! I have some more questions though...
>
> I downloaded the source code for alsa-lib-1.0.15
> Based on the code, if the format is SND_PCM_FORMAT_MU_LAW, I am not sure
> why it does a get/put index to SND_PCM_FORMAT_S16 Also, if the stream is
> SND_PCM_STREAM_PLAYBACK, then I would think that it should decode the
> data. Why does it call snd_pcm_mulaw_decode function if the format is
> SND_PCM_FORMAT_MU_LAW and snd_pcm_mulaw_encode otherwise. I have an
> Intel HDA soundcard and according to the specs, it should support PCM
> ulaw format.
>
> All ALSA documentation and examples I have come across use specific
> hw_params (like sample rate of 44100, SND_PCM_FORMAT_S16, 2 channel
> interleaved data). According to the documents, hw_params refer to the
> stream related info so that's the reason I tried to change it to that of
> mu-law (sampling rate of 8000 Hz, SND_PCM_FORMAT_MU_LAW etc). Not sure
> if that's the way to do it though. Based on the code it looks like the
> hardware just seems to support SND_PCM_FORMAT_S16. Any pointers to help
> me better understand the ALSA code would be much appreciated.
>
>
Hi Misen,
First, a gentle remonstrance. You probably have noticed that I always
put my responses after or mixed with your message. On public mailing
lists this is considered good form, rather than posting your response at
the top of the message. Why? So that anyone who steps into the
interaction doesn't have to read the messages out of order and that
future searchers have an easier time understanding the message. While
top posting is the norm in communications between two or a few people
because the context is familiar to all and it saves time not to have to
look for the response, on a public mailing list that isn't necessarily true.
Now to the matter at hand.
I had never heard of mu law so I looked it up.
http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml
...
Standard companding algorithm used in digital communications systems in
North America and Japan (telephones, for the most part) to optimize the
dynamic range of an analog signal (generally a voice) for digitizing,
i.e., to compress 16 bit LPCM
<http://www.digitalpreservation.gov/formats/fdd/fdd000011.shtml> (Linear
Pulse Code Modulated) data down to 8 bits of logarithmic data. See also
Notes
<http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml#notes>
below. µ-Law is similar to the A-Law
<http://www.digitalpreservation.gov/formats/fdd/fdd000038.shtml>
algorithm used in Europe.
...
The code that you extracted below is designed to convert mu law from the
compressed form back into the 16 bit signed form. I haven't checked the
rest of the code myself, but it appears to assume that the sound device
is incapable of internal conversion. If that is true, you shouldn't
have to specify anything else to the library except mu law. It should
take care of everything else. i.e. as soon as you specify mu law, it is
known that the stream is 8 bit mono that has to be uncompressed to 16
bit mono. I presume that is why there is the error when you try to set
the hardware parms with mu law. The library should probably be modified
to use this new capability of sound device internal conversion for mu
law if it is available on the sound device. Maybe it already does; as
I said I haven't looked at the code, and I'm not really familiar with mu
law.
So, given my ignorance, my explanation and proposed solution might be
completely wrong. :-) Perhaps a developer familiar with the coding of
mu law will give a better explanation.
At this point, I really don't have more to offer for your problem. I
would have to look at the code to decipher it in order to give an
answer. You might as well do that yourself, as you will get a better
understanding than I could give with an explanation.
> The code that I am referring to is in pcm_mulaw.c and is as follows:-
>
> static int snd_pcm_mulaw_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *
> params)
> {
> snd_pcm_mulaw_t *mulaw = pcm->private_data;
> snd_pcm_format_t format;
> int err = snd_pcm_hw_params_slave(pcm, params,
>
> snd_pcm_mulaw_hw_refine_cchange,
>
> snd_pcm_mulaw_hw_refine_sprepare,
>
> snd_pcm_mulaw_hw_refine_schange,
> snd_pcm_generic_hw_params);
> if (err < 0)
> return err;
>
> err = INTERNAL(snd_pcm_hw_params_get_format)(params, &format);
> if (err < 0)
> return err;
>
> if (pcm->stream == SND_PCM_STREAM_PLAYBACK) {
> if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> mulaw->getput_idx =
> snd_pcm_linear_get_index(format, SND_PCM_FORMAT_S16);
> mulaw->func = snd_pcm_mulaw_encode;
> } else {
> mulaw->getput_idx =
> snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, mulaw->sformat);
> mulaw->func = snd_pcm_mulaw_decode;
> }
> } else {
> if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> mulaw->getput_idx =
> snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, format);
> mulaw->func = snd_pcm_mulaw_decode;
> } else {
> mulaw->getput_idx =
> snd_pcm_linear_get_index(mulaw->sformat, SND_PCM_FORMAT_S16);
> mulaw->func = snd_pcm_mulaw_encode;
> }
> }
> return 0;
> }
>
> Thanks and regards,
> Mitul
>
> -----Or
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-02 2:20 ` stan
@ 2008-07-03 18:55 ` Mitul Sen (misen)
2008-07-16 23:36 ` Mitul Sen (misen)
1 sibling, 0 replies; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-03 18:55 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
> -----Original Message-----
> From: stan [mailto:ghjeold_i_mwee@cox.net]
> Sent: Tuesday, July 01, 2008 7:20 PM
> To: Mitul Sen (misen)
> Cc: alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Setting format to
> SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
>
> Mitul Sen (misen) wrote:
> > Hi Stan,
> >
> > Thanks for all your help! I have some more questions though...
> >
> > I downloaded the source code for alsa-lib-1.0.15 Based on
> the code, if
> > the format is SND_PCM_FORMAT_MU_LAW, I am not sure why it does a
> > get/put index to SND_PCM_FORMAT_S16 Also, if the stream is
> > SND_PCM_STREAM_PLAYBACK, then I would think that it should
> decode the
> > data. Why does it call snd_pcm_mulaw_decode function if the
> format is
> > SND_PCM_FORMAT_MU_LAW and snd_pcm_mulaw_encode otherwise. I have an
> > Intel HDA soundcard and according to the specs, it should
> support PCM
> > ulaw format.
> >
> > All ALSA documentation and examples I have come across use specific
> > hw_params (like sample rate of 44100, SND_PCM_FORMAT_S16, 2 channel
> > interleaved data). According to the documents, hw_params
> refer to the
> > stream related info so that's the reason I tried to change
> it to that
> > of mu-law (sampling rate of 8000 Hz, SND_PCM_FORMAT_MU_LAW
> etc). Not
> > sure if that's the way to do it though. Based on the code it looks
> > like the hardware just seems to support SND_PCM_FORMAT_S16. Any
> > pointers to help me better understand the ALSA code would
> be much appreciated.
> >
> >
>
> Hi Misen,
>
> First, a gentle remonstrance. You probably have noticed that
> I always put my responses after or mixed with your message.
> On public mailing lists this is considered good form, rather
> than posting your response at the top of the message. Why?
> So that anyone who steps into the interaction doesn't have to
> read the messages out of order and that future searchers have
> an easier time understanding the message. While top posting
> is the norm in communications between two or a few people
> because the context is familiar to all and it saves time not
> to have to look for the response, on a public mailing list
> that isn't necessarily true.
Point noted!
>
> Now to the matter at hand.
> I had never heard of mu law so I looked it up.
> http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml
> ...
> Standard companding algorithm used in digital communications
> systems in North America and Japan (telephones, for the most
> part) to optimize the dynamic range of an analog signal
> (generally a voice) for digitizing, i.e., to compress 16 bit
> LPCM
> <http://www.digitalpreservation.gov/formats/fdd/fdd000011.shtm
> l> (Linear Pulse Code Modulated) data down to 8 bits of
> logarithmic data. See also Notes
> <http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml#notes>
> below. µ-Law is similar to the A-Law
> <http://www.digitalpreservation.gov/formats/fdd/fdd000038.shtml>
> algorithm used in Europe.
> ...
>
> The code that you extracted below is designed to convert mu
> law from the compressed form back into the 16 bit signed
> form. I haven't checked the rest of the code myself, but it
> appears to assume that the sound device is incapable of
> internal conversion. If that is true, you shouldn't have to
> specify anything else to the library except mu law. It
> should take care of everything else. i.e. as soon as you
> specify mu law, it is known that the stream is 8 bit mono
> that has to be uncompressed to 16
> bit mono. I presume that is why there is the error when you
> try to set
> the hardware parms with mu law.
Thanks! You are right. I don't get the error when I only specify mu law and let the library convert it to 16 bit signed form. I can now hear "some" audio but it sounds very faint. I have been playing around with the frame size because I seem to be able to hear the audio only when I use a small frame size. I need to get a better understanding of the code and my sound device to improve the audio quality. For now, at least I am able to set the hardware parms with mulaw.
> The library should probably
> be modified to use this new capability of sound device
> internal conversion for mu law if it is available on the
> sound device. Maybe it already does; as I said I haven't
> looked at the code, and I'm not really familiar with mu law.
>
> So, given my ignorance, my explanation and proposed solution
> might be completely wrong. :-) Perhaps a developer familiar
> with the coding of mu law will give a better explanation.
>
> At this point, I really don't have more to offer for your
> problem. I would have to look at the code to decipher it in
> order to give an answer. You might as well do that yourself,
> as you will get a better understanding than I could give with
> an explanation.
> > The code that I am referring to is in pcm_mulaw.c and is as
> follows:-
> >
> > static int snd_pcm_mulaw_hw_params(snd_pcm_t *pcm,
> snd_pcm_hw_params_t
> > *
> > params)
> > {
> > snd_pcm_mulaw_t *mulaw = pcm->private_data;
> > snd_pcm_format_t format;
> > int err = snd_pcm_hw_params_slave(pcm, params,
> >
> > snd_pcm_mulaw_hw_refine_cchange,
> >
> > snd_pcm_mulaw_hw_refine_sprepare,
> >
> > snd_pcm_mulaw_hw_refine_schange,
> >
> snd_pcm_generic_hw_params);
> > if (err < 0)
> > return err;
> >
> > err =
> INTERNAL(snd_pcm_hw_params_get_format)(params, &format);
> > if (err < 0)
> > return err;
> >
> > if (pcm->stream == SND_PCM_STREAM_PLAYBACK) {
> > if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> > mulaw->getput_idx =
> > snd_pcm_linear_get_index(format, SND_PCM_FORMAT_S16);
> > mulaw->func = snd_pcm_mulaw_encode;
> > } else {
> > mulaw->getput_idx =
> > snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, mulaw->sformat);
> > mulaw->func = snd_pcm_mulaw_decode;
> > }
> > } else {
> > if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> > mulaw->getput_idx =
> > snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, format);
> > mulaw->func = snd_pcm_mulaw_decode;
> > } else {
> > mulaw->getput_idx =
> > snd_pcm_linear_get_index(mulaw->sformat, SND_PCM_FORMAT_S16);
> > mulaw->func = snd_pcm_mulaw_encode;
> > }
> > }
> > return 0;
> > }
> >
> > Thanks and regards,
> > Mitul
> >
> > -----Or
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-02 2:20 ` stan
2008-07-03 18:55 ` Mitul Sen (misen)
@ 2008-07-16 23:36 ` Mitul Sen (misen)
2008-07-17 3:30 ` stan
1 sibling, 1 reply; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-16 23:36 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
Hi,
> -----Original Message-----
> From: stan [mailto:ghjeold_i_mwee@cox.net]
> Sent: Tuesday, July 01, 2008 7:20 PM
> To: Mitul Sen (misen)
> Cc: alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Setting format to
> SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
>
> Mitul Sen (misen) wrote:
> > Hi Stan,
> >
> > Thanks for all your help! I have some more questions though...
> >
> > I downloaded the source code for alsa-lib-1.0.15 Based on
> the code, if
> > the format is SND_PCM_FORMAT_MU_LAW, I am not sure why it does a
> > get/put index to SND_PCM_FORMAT_S16 Also, if the stream is
> > SND_PCM_STREAM_PLAYBACK, then I would think that it should
> decode the
> > data. Why does it call snd_pcm_mulaw_decode function if the
> format is
> > SND_PCM_FORMAT_MU_LAW and snd_pcm_mulaw_encode otherwise. I have an
> > Intel HDA soundcard and according to the specs, it should
> support PCM
> > ulaw format.
> >
> > All ALSA documentation and examples I have come across use specific
> > hw_params (like sample rate of 44100, SND_PCM_FORMAT_S16, 2 channel
> > interleaved data). According to the documents, hw_params
> refer to the
> > stream related info so that's the reason I tried to change
> it to that
> > of mu-law (sampling rate of 8000 Hz, SND_PCM_FORMAT_MU_LAW
> etc). Not
> > sure if that's the way to do it though. Based on the code it looks
> > like the hardware just seems to support SND_PCM_FORMAT_S16. Any
> > pointers to help me better understand the ALSA code would
> be much appreciated.
> >
> >
>
> Hi Misen,
>
> First, a gentle remonstrance. You probably have noticed that
> I always put my responses after or mixed with your message.
> On public mailing lists this is considered good form, rather
> than posting your response at the top of the message. Why?
> So that anyone who steps into the interaction doesn't have to
> read the messages out of order and that future searchers have
> an easier time understanding the message. While top posting
> is the norm in communications between two or a few people
> because the context is familiar to all and it saves time not
> to have to look for the response, on a public mailing list
> that isn't necessarily true.
>
> Now to the matter at hand.
> I had never heard of mu law so I looked it up.
> http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml
> ...
> Standard companding algorithm used in digital communications
> systems in North America and Japan (telephones, for the most
> part) to optimize the dynamic range of an analog signal
> (generally a voice) for digitizing, i.e., to compress 16 bit
> LPCM
> <http://www.digitalpreservation.gov/formats/fdd/fdd000011.shtm
> l> (Linear Pulse Code Modulated) data down to 8 bits of
> logarithmic data. See also Notes
> <http://www.digitalpreservation.gov/formats/fdd/fdd000039.shtml#notes>
> below. µ-Law is similar to the A-Law
> <http://www.digitalpreservation.gov/formats/fdd/fdd000038.shtml>
> algorithm used in Europe.
> ...
>
> The code that you extracted below is designed to convert mu
> law from the compressed form back into the 16 bit signed
> form. I haven't checked the rest of the code myself, but it
> appears to assume that the sound device is incapable of
> internal conversion. If that is true, you shouldn't have to
> specify anything else to the library except mu law. It
> should take care of everything else. i.e. as soon as you
> specify mu law, it is known that the stream is 8 bit mono
> that has to be uncompressed to 16
> bit mono. I presume that is why there is the error when you
> try to set
> the hardware parms with mu law. The library should probably
> be modified to use this new capability of sound device
> internal conversion for mu law if it is available on the
> sound device. Maybe it already does; as I said I haven't
> looked at the code, and I'm not really familiar with mu law.
>
I am making some changes to the alsa-lib code and I have built alsa-lib. But I don't think its really picking up my changes. How can I make sure that my application uses the modified library? I don't have to load any modules, do I? I am sorry if this is too basic a question but I couldn't find the info on a quick google search. Basically what I want to know is what are the steps to develop alsa-lib. This is what I did
1) Downloaded the source code
2) Configured the system using ./configure
3) Did a build using make
4) Did a "make install"
Am I missing something here?
Also regarding the original problem, when I run my program, the output of /proc/asound/card0/pcm0p/sub0/hw_params is
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 32
buffer_size: 1024
This is clearly not what it should be since the data access should be RW_NONINTERLEAVED, format should be MU_LAW, there is only one channel and rate is 8000. Which would mean that alsa assumes a different set of parameters (for mu law)from what the data actually is. Am I right in thinking this?
Just got back after a long break and trying to pick up the threads again:-)
Again, any help will be much appreciated.
> So, given my ignorance, my explanation and proposed solution
> might be completely wrong. :-) Perhaps a developer familiar
> with the coding of mu law will give a better explanation.
>
> At this point, I really don't have more to offer for your
> problem. I would have to look at the code to decipher it in
> order to give an answer. You might as well do that yourself,
> as you will get a better understanding than I could give with
> an explanation.
> > The code that I am referring to is in pcm_mulaw.c and is as
> follows:-
> >
> > static int snd_pcm_mulaw_hw_params(snd_pcm_t *pcm,
> snd_pcm_hw_params_t
> > *
> > params)
> > {
> > snd_pcm_mulaw_t *mulaw = pcm->private_data;
> > snd_pcm_format_t format;
> > int err = snd_pcm_hw_params_slave(pcm, params,
> >
> > snd_pcm_mulaw_hw_refine_cchange,
> >
> > snd_pcm_mulaw_hw_refine_sprepare,
> >
> > snd_pcm_mulaw_hw_refine_schange,
> >
> snd_pcm_generic_hw_params);
> > if (err < 0)
> > return err;
> >
> > err =
> INTERNAL(snd_pcm_hw_params_get_format)(params, &format);
> > if (err < 0)
> > return err;
> >
> > if (pcm->stream == SND_PCM_STREAM_PLAYBACK) {
> > if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> > mulaw->getput_idx =
> > snd_pcm_linear_get_index(format, SND_PCM_FORMAT_S16);
> > mulaw->func = snd_pcm_mulaw_encode;
> > } else {
> > mulaw->getput_idx =
> > snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, mulaw->sformat);
> > mulaw->func = snd_pcm_mulaw_decode;
> > }
> > } else {
> > if (mulaw->sformat == SND_PCM_FORMAT_MU_LAW) {
> > mulaw->getput_idx =
> > snd_pcm_linear_put_index(SND_PCM_FORMAT_S16, format);
> > mulaw->func = snd_pcm_mulaw_decode;
> > } else {
> > mulaw->getput_idx =
> > snd_pcm_linear_get_index(mulaw->sformat, SND_PCM_FORMAT_S16);
> > mulaw->func = snd_pcm_mulaw_encode;
> > }
> > }
> > return 0;
> > }
> >
> > Thanks and regards,
> > Mitul
> >
> > -----Or
>
>
Thanks,
Mitul
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-16 23:36 ` Mitul Sen (misen)
@ 2008-07-17 3:30 ` stan
2008-07-23 0:11 ` Mitul Sen (misen)
0 siblings, 1 reply; 15+ messages in thread
From: stan @ 2008-07-17 3:30 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
>
> I am making some changes to the alsa-lib code and I have built alsa-lib. But I don't think its really picking up my changes. How can I make sure that my application uses the
modified library? I don't have to load any modules, do
I? I am sorry if this is too basic a question but I
couldn't find the info on a quick google search.
Basically what I want to know is what are the steps to
develop alsa-lib. This is what I did
> 1) Downloaded the source code
> 2) Configured the system using ./configure
> 3) Did a build using make
> 4) Did a "make install"
>
> Am I missing something here?
It looks correct. Do an ls -l /usr/lib/libasound*.
The file there should have the same timestamp as the
file in your build directory. If it doesn't, it didn't
install. You could just copy it over.
Make sure there is no other copy in /lib.
>
> Also regarding the original problem, when I run my program, the output of /proc/asound/card0/pcm0p/sub0/hw_params is
>
> access: MMAP_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 48000 (48000/1)
> period_size: 32
> buffer_size: 1024
>
> This is clearly not what it should be since the data access should be RW_NONINTERLEAVED, format should be MU_LAW, there is only one channel and rate is 8000. Which would mean that alsa assumes a different set of parameters (for mu law)from what the data actually is. Am I right in thinking this?
>
> Just got back after a long break and trying to pick up the threads again:-)
>
> Again, any help will be much appreciated.
>
>
>
Unless your changes changed the mu-law code to use your
card's mu-law decoder, they will still be the decoded
values.
The best way to do this is to compile your program with
debugging enabled ( -ggdb -O0) and the alsa library
with debugging enabled. ./configure --help should
give you the option. Then move only the library to
/usr/lib and run your program as
gdb --args yourprogram yourargs . You can see the
info on how to run gdb in info gdb . With the
debugger you can step through the program and the
library to see where it is not working the way you
expected. But you don't want to leave it like that as
it is very inefficient.
If your code works for the mu-law, you could submit a
patch. Of course, you would have to check for the
functionality and branch to the old code if the card
doesn't support mu-law decoding.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-17 3:30 ` stan
@ 2008-07-23 0:11 ` Mitul Sen (misen)
2008-07-23 18:25 ` stan
0 siblings, 1 reply; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-23 0:11 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
Hi,
> -----Original Message-----
> From: stan [mailto:ghjeold_i_mwee@cox.net]
> Sent: Wednesday, July 16, 2008 8:30 PM
> To: Mitul Sen (misen)
> Cc: alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Setting format to
> SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
>
> Mitul Sen (misen) wrote:
>
> >
> > I am making some changes to the alsa-lib code and I have built
> > alsa-lib. But I don't think its really picking up my
> changes. How can
> > I make sure that my application uses the
> modified library? I don't have to load any modules, do I? I
> am sorry if this is too basic a question but I couldn't find
> the info on a quick google search.
> Basically what I want to know is what are the steps to
> develop alsa-lib. This is what I did
> > 1) Downloaded the source code
> > 2) Configured the system using ./configure
> > 3) Did a build using make
> > 4) Did a "make install"
> >
> > Am I missing something here?
>
> It looks correct. Do an ls -l /usr/lib/libasound*.
> The file there should have the same timestamp as the file in
> your build directory. If it doesn't, it didn't install. You
> could just copy it over.
>
> Make sure there is no other copy in /lib.
>
I have checked the timestamps for libasound.so and the soft links
created in the /usr/lib directory after an install. They are the same as
in my build directory.
> >
> > Also regarding the original problem, when I run my program,
> the output
> > of /proc/asound/card0/pcm0p/sub0/hw_params is
> >
> > access: MMAP_INTERLEAVED
> > format: S16_LE
> > subformat: STD
> > channels: 2
> > rate: 48000 (48000/1)
> > period_size: 32
> > buffer_size: 1024
> >
> > This is clearly not what it should be since the data access
> should be RW_NONINTERLEAVED, format should be MU_LAW, there
> is only one channel and rate is 8000. Which would mean that
> alsa assumes a different set of parameters (for mu law)from
> what the data actually is. Am I right in thinking this?
> >
> > Just got back after a long break and trying to pick up the threads
> > again:-)
> >
> > Again, any help will be much appreciated.
> >
> >
> >
>
> Unless your changes changed the mu-law code to use your
> card's mu-law decoder, they will still be the decoded values.
>
> The best way to do this is to compile your program with
> debugging enabled ( -ggdb -O0) and the alsa library with
> debugging enabled. ./configure --help should give you the
> option. Then move only the library to /usr/lib and run your
> program as
> gdb --args yourprogram yourargs . You can see the
> info on how to run gdb in info gdb . With the debugger you
> can step through the program and the library to see where it
> is not working the way you expected. But you don't want to
> leave it like that as it is very inefficient.
>
> If your code works for the mu-law, you could submit a patch.
> Of course, you would have to check for the functionality and
> branch to the old code if the card doesn't support mu-law decoding.
>
I have tried using gdb both from the command line as you suggested and
also from within eclipse. Even though I can step through the code and
break properly, I think there is some mismatch between the source code
and object code used by gdb. I say that because it sometimes steps
through code in a way that makes no sense. For example, I see that a
particular 'if' condition is satified and it goes into the 'if' clause
and then again goes into the 'else' clause that is not expected. Is
there any module that needs to be reloaded after building and installing
the shared library? I have done a clean make at all times, checked
timestamps, even rebooted the machine in case some driver related data
needs to be reloaded at startup but none of this has helped.
Another thing that I notice is that when I use aplay to play the rtp
data that I save to file (before writing to the sound device), and check
the output of /proc/asound/card0/pcm0p/sub0/hw_params file, it is
exactly the same as when I run my application. Using aplay does the
playback properly even though hw_params still shows as
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
Please note that I can play back the file using aplay, I only have the
problem of bad audio when I try to write to the sound device in
real-time. With this observation though I am not sure if the fact that
the library seems to not use the card's decoder is really the problem. I
am trying to look into the source code of aplay to see if I can spot any
difference in the way the data is written to the buffer.
Meanwhile, any comments and help will be greatly appreciated as usual.
Thanks for your help.
Regards,
Mitul
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-23 0:11 ` Mitul Sen (misen)
@ 2008-07-23 18:25 ` stan
2008-07-23 21:31 ` Mitul Sen (misen)
0 siblings, 1 reply; 15+ messages in thread
From: stan @ 2008-07-23 18:25 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
> Hi,
>
> I have tried using gdb both from the command line as you suggested and
> also from within eclipse. Even though I can step through the code and
> break properly, I think there is some mismatch between the source code
> and object code used by gdb. I say that because it sometimes steps
> through code in a way that makes no sense. For example, I see that a
> particular 'if' condition is satified and it goes into the 'if' clause
> and then again goes into the 'else' clause that is not expected. Is
> there any module that needs to be reloaded after building and installing
> the shared library? I have done a clean make at all times, checked
> timestamps, even rebooted the machine in case some driver related data
> needs to be reloaded at startup but none of this has helped.
I suspect you are debugging optimized code. The
optimizer rearranges and deletes instructions. Did you
specify -O0 so that no optimization occurs? The other
gotcha in the alsa-lib code is that some of the
functions are actually macros. They cannot be stepped
through. When you hit them in the debugger it is
disconcerting.
>
> Another thing that I notice is that when I use aplay to play the rtp
> data that I save to file (before writing to the sound device), and check
> the output of /proc/asound/card0/pcm0p/sub0/hw_params file, it is
> exactly the same as when I run my application. Using aplay does the
> playback properly even though hw_params still shows as
>
> access: MMAP_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 48000 (48000/1)
It is decoding it before it is playing it, it must be
calling a routine somewhere to do that, or else it is
built in.
>
> Please note that I can play back the file using aplay, I only have the
> problem of bad audio when I try to write to the sound device in
> real-time. With this observation though I am not sure if the fact that
> the library seems to not use the card's decoder is really the problem. I
> am trying to look into the source code of aplay to see if I can spot any
> difference in the way the data is written to the buffer.
>
Good not to limit the possibilities you are examining.
> Meanwhile, any comments and help will be greatly appreciated as usual.
>
> Thanks for your help.
>
> Regards,
> Mitul
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-23 18:25 ` stan
@ 2008-07-23 21:31 ` Mitul Sen (misen)
2008-07-24 0:46 ` stan
0 siblings, 1 reply; 15+ messages in thread
From: Mitul Sen (misen) @ 2008-07-23 21:31 UTC (permalink / raw)
To: stan; +Cc: alsa-devel
Hi,
> -----Original Message-----
> From: stan [mailto:ghjeold_i_mwee@cox.net]
> Sent: Wednesday, July 23, 2008 11:26 AM
> To: Mitul Sen (misen)
> Cc: alsa-devel@alsa-project.org
> Subject: Re: [alsa-devel] Setting format to
> SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
>
> Mitul Sen (misen) wrote:
> > Hi,
> >
> > I have tried using gdb both from the command line as you
> suggested and
> > also from within eclipse. Even though I can step through
> the code and
> > break properly, I think there is some mismatch between the
> source code
> > and object code used by gdb. I say that because it sometimes steps
> > through code in a way that makes no sense. For example, I
> see that a
> > particular 'if' condition is satified and it goes into the
> 'if' clause
> > and then again goes into the 'else' clause that is not expected. Is
> > there any module that needs to be reloaded after building and
> > installing the shared library? I have done a clean make at
> all times,
> > checked timestamps, even rebooted the machine in case some driver
> > related data needs to be reloaded at startup but none of
> this has helped.
> I suspect you are debugging optimized code. The optimizer
> rearranges and deletes instructions. Did you specify -O0 so
> that no optimization occurs? The other gotcha in the
> alsa-lib code is that some of the functions are actually
> macros. They cannot be stepped through. When you hit them
> in the debugger it is disconcerting.
> >
I did specify -O0 to disable optimizations.
> > Another thing that I notice is that when I use aplay to
> play the rtp
> > data that I save to file (before writing to the sound device), and
> > check the output of /proc/asound/card0/pcm0p/sub0/hw_params
> file, it
> > is exactly the same as when I run my application. Using
> aplay does the
> > playback properly even though hw_params still shows as
> >
> > access: MMAP_INTERLEAVED
> > format: S16_LE
> > subformat: STD
> > channels: 2
> > rate: 48000 (48000/1)
> It is decoding it before it is playing it, it must be calling
> a routine somewhere to do that, or else it is built in.
> >
> > Please note that I can play back the file using aplay, I
> only have the
> > problem of bad audio when I try to write to the sound device in
> > real-time. With this observation though I am not sure if
> the fact that
> > the library seems to not use the card's decoder is really
> the problem.
> > I am trying to look into the source code of aplay to see if
> I can spot
> > any difference in the way the data is written to the buffer.
> >
> Good not to limit the possibilities you are examining.
> > Meanwhile, any comments and help will be greatly
> appreciated as usual.
> >
> > Thanks for your help.
> >
> > Regards,
> > Mitul
> >
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
2008-07-23 21:31 ` Mitul Sen (misen)
@ 2008-07-24 0:46 ` stan
0 siblings, 0 replies; 15+ messages in thread
From: stan @ 2008-07-24 0:46 UTC (permalink / raw)
To: Mitul Sen (misen); +Cc: alsa-devel
Mitul Sen (misen) wrote:
> Hi,
>
>> -----Original Message-----
>> From: stan [mailto:ghjeold_i_mwee@cox.net]
>> Sent: Wednesday, July 23, 2008 11:26 AM
>> To: Mitul Sen (misen)
>> Cc: alsa-devel@alsa-project.org
>> Subject: Re: [alsa-devel] Setting format to
>> SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters
>>
>> Mitul Sen (misen) wrote:
>>> Hi,
>>>
>>> I have tried using gdb both from the command line as you
>> suggested and
>>> also from within eclipse. Even though I can step through
>> the code and
>>> break properly, I think there is some mismatch between the
>> source code
>>> and object code used by gdb. I say that because it sometimes steps
>>> through code in a way that makes no sense. For example, I
>> see that a
>>> particular 'if' condition is satified and it goes into the
>> 'if' clause
>>> and then again goes into the 'else' clause that is not expected. Is
>>> there any module that needs to be reloaded after building and
>>> installing the shared library? I have done a clean make at
>> all times,
>>> checked timestamps, even rebooted the machine in case some driver
>>> related data needs to be reloaded at startup but none of
>> this has helped.
/sbin/ldconfig refreshes the links for libraries.
>> I suspect you are debugging optimized code. The optimizer
>> rearranges and deletes instructions. Did you specify -O0 so
>> that no optimization occurs? The other gotcha in the
>> alsa-lib code is that some of the functions are actually
>> macros. They cannot be stepped through. When you hit them
>> in the debugger it is disconcerting.
>
> I did specify -O0 to disable optimizations.
>
That's weird. Don't have an explanation except yours,
that you aren't debugging the code you think you are.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-07-24 0:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-30 22:09 Setting format to SND_PCM_FORMAT_MU_LAW does not let me apply hardware parameters Mitul Sen (misen)
2008-07-01 7:39 ` Clemens Ladisch
2008-07-01 17:01 ` Mitul Sen (misen)
2008-07-01 13:59 ` stan
2008-07-01 18:42 ` Mitul Sen (misen)
2008-07-01 22:12 ` stan
2008-07-01 23:50 ` Mitul Sen (misen)
2008-07-02 2:20 ` stan
2008-07-03 18:55 ` Mitul Sen (misen)
2008-07-16 23:36 ` Mitul Sen (misen)
2008-07-17 3:30 ` stan
2008-07-23 0:11 ` Mitul Sen (misen)
2008-07-23 18:25 ` stan
2008-07-23 21:31 ` Mitul Sen (misen)
2008-07-24 0:46 ` stan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.