[alsa-devel] issue at 44.1 Khz capturing
Hi,
I am using arecord for capturing data. When I try to record at 8 or 48 KHz, it's perfectly fine. But when I try to record at 44.1 Khz, there are spikes in the recorded data for every buffer. When I tried to tap the data captured at the firmware/hardware end, it's smooth but the same data when is checked from the user space after being recorded, it has spikes. On further analysis, looks like for every buffer recorded there is either 1 sample recorded extra or 1 sample dropped. But when I printed out the values passed from the pointer function, they are exactly at the intervals of 5513 bytes.
Can anyone give me any clue as to what is going wrong? I am using indirect_* functions in the driver code. Is there any buffer size round off that is giving this error? Can I handle something in the driver to avoid this?
Thanks, Harsha.
2009/8/10 Harsha, Priya priya.harsha@intel.com:
Hi,
I am using arecord for capturing data. When I try to record at 8 or 48 KHz, it's perfectly fine. But when I try to record at 44.1 Khz, there are spikes in the recorded data for every buffer. When I tried to tap the data captured at the firmware/hardware end, it's smooth but the same data when is checked from the user space after being recorded, it has spikes. On further analysis, looks like for every buffer recorded there is either 1 sample recorded extra or 1 sample dropped. But when I printed out the values passed from the pointer function, they are exactly at the intervals of 5513 bytes.
Can anyone give me any clue as to what is going wrong? I am using indirect_* functions in the driver code. Is there any buffer size round off that is giving this error? Can I handle something in the driver to avoid this?
A lot of sound card hardware cannot work at anything other than 48kHz. alsa is therefore resampling to the applications rate. In this case trying to get 44.1kHz. It is very difficult with the current alsa architecture to get good quality resampling. I would advise you to record at 48kHz and use something like SOX afterwards, to get 44.1kHz. Note that also sound cards are not good at playing 44.1kHz because the same resampling happens. So keeping everything at 48kHz now days is probably best.
Kind Regards
James
Harsha, Priya wrote:
... But when I printed out the values passed from the pointer function, they are exactly at the intervals of 5513 bytes.
What is the exact buffer size? Half a second would be 22050 bytes (frames?), while four of your periods are 22052 bytes. Does your hardware support buffers whose length is not an integer multiple of the period size?
Best regards, Clemens
I see that the buffer allocated is 22050 bytes (and not 22052 bytes). Yes the hardware supports buffers which are not multiple of period size.
Can I forcefully set my buffer size to 22052 bytes and allocate using snd_pcm_lib_malloc_pages and try? Will that help?
Thanks, Harsha.
-----Original Message----- From: Clemens Ladisch [mailto:clemens@ladisch.de] Sent: Monday, August 10, 2009 5:21 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] issue at 44.1 Khz capturing
Harsha, Priya wrote:
... But when I printed out the values passed from the pointer function, they are exactly at the intervals of 5513 bytes.
What is the exact buffer size? Half a second would be 22050 bytes (frames?), while four of your periods are 22052 bytes. Does your hardware support buffers whose length is not an integer multiple of the period size?
Best regards, Clemens
(please don't top-post)
Harsha, Priya wrote:
I see that the buffer allocated is 22050 bytes (and not 22052 bytes). Yes the hardware supports buffers which are not multiple of period size.
But there may be a (driver) bug that affects the last byte. Try calling
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
in the open callback.
Can I forcefully set my buffer size to 22052 bytes
Try the --buffer-size and --period-size parameters of arecord.
HTH Clemens
participants (3)
-
Clemens Ladisch -
Harsha, Priya -
James Courtier-Dutton