issue at 44.1 Khz capturing

issue at 44.1 Khz capturing

[Harsha, Priya]

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.

Re: issue at 44.1 Khz capturing

[James Courtier-Dutton]

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

Re: issue at 44.1 Khz capturing

[Clemens Ladisch]

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

Re: issue at 44.1 Khz capturing

[Harsha, Priya]

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

Re: issue at 44.1 Khz capturing

[Clemens Ladisch]

(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