[alsa-devel] Alsa Crackling Noise

[Caleb Crome]

On Fri, Nov 6, 2015 at 9:27 AM, Dinesh Ravindran <rite2dinesh at gmail.com> wrote:
> The USB soundcard natively supports the sampling rate of 8kHz. We tried with
> all three options of the kernel preemption model, and it doesn't make any
> difference. The CPU utilization is almost zero, and interestingly when the
> CPU consumption is high the audio sounds better(we notice when we copy a
> file via ssh, cpu consumption goes upto 33%).
>
> The default premption model is set to none, however we tried with both
> voluntary and Low-Latency Desktop, it doesn't make any difference.
>
> One thing we noticed was that even though from our application(or aplay) we
> set the access to SND_PCM_ACCESS_RW_INTERLEAVED,
> /proc/asound/card0/pcm0p/sub0/hw_params shows it as MMAP_INTERLEAVED, we're
> not sure why it is so and what the impact could be.
>
> Does it has to do with the low level USB transfer, where it it waiting for
> more data to transfer it in one shot,  because, at higher sampling rate we
> have more data to transfer. But it still doesn't explain why printing some
> debug statements or having a larger alsa buffer works.
>
>

That is certainly strange.  Sorry I don't know how to help.  Perhaps
somebody else can shed some light.

-Caleb



>
>
> best regards
> Dinesh
>
> On Fri, Nov 6, 2015 at 5:37 PM, Caleb Crome <caleb at crome.org> wrote:
>>
>> On Fri, Nov 6, 2015 at 1:59 AM, Dinesh Ravindran <rite2dinesh at gmail.com>
>> wrote:
>> > We have been facing a weird issue with Alsa recently. Sometimes the
>> > audio
>> > plays out with out any noise and sometimes it has lot of cracking noise,
>> > really a lot. The weird situation is when another application is
>> > printing
>> > out some debug statements to a console it sounds good. The behavior is
>> > same
>> > with a custom developed alsa application and also with aplay. Any
>> > thoughts?
>> > If we have a really big buffer size of around 2sec it works somehow, but
>> > we
>> > really want to analyze why alsa exhibits this strange behavior. Is it
>> > the
>> > alsa itself or is it just a symptom of a bigger issue at system level?
>> >
>> > All the test we are carrying out it at 8KHz, at higher sampling
>> > rate(48k)
>> > we do not see this behaviour.
>> >
>> >
>> > These are the scenarios in which it sounds good:
>> > 1. If any application is printing to the console while audio is being
>> > played out or even just holding the return button on the console helps.
>> > 2. If we enable xrun debug with echo 29 >
>> > /proc/asound/card0/pcm0p/xrun_debug it sounds good.
>> > 3. If we have really big buffer size around 2 seconds.
>> > 4. Or sometimes on fresh start of the machine until it enters xrun state
>> > once.
>> >
>> >
>> >
>> > We have the following setup:
>> >
>> > Processor: ARM926EJ-S
>>
>> What's your CPU utilization when playing 8kHz?  It's interesting that
>> 48kHz has no problem, but 8kHz does.  My first guess would be that
>> alsa is forced to resample in software, causing the cpu load to go up.
>>    Do you know what rates your actual codec can run at?
>>
>> Others on this list are infinitely more likely to know the true answer :-)
>>
>> Another question: what's the preemption model in your kernel config?
>> under kernel features->Preemption model?  You can also check your
>> .config for CONFIG_PREEMPT=y
>>
>> -Caleb
>>
>> > Kernel: 3.14.53
>> > Alsa-lib: 1.0.29
>> > Alsa-Util: 1.0.29
>> > Audio Chip: CONEXANT USB AUDIO
>> >
>> >> aplay -Dplughw:0,0 8kz_8000.wav  #to play file
>> >
>> >
>> > cat /proc/asound/card0/stream0
>> > ----------------------------------------
>> >
>> > Playback:
>> >   Status: Stop
>> >   Interface 2
>> >     Altset 1
>> >     Format: S16_LE
>> >     Channels: 2
>> >     Endpoint: 1 OUT (ADAPTIVE)
>> >     Rates: 8000, 16000, 24000, 32000, 44100, 48000
>> >
>> > Hw params:
>> > --------------
>> >
>> > access: MMAP_INTERLEAVED
>> > format: S16_LE
>> > subformat: STD
>> > channels: 2
>> > rate: 8000 (8000/1)
>> > period_size: 1000
>> > buffer_size: 4000
>> >
>> > sw params:
>> > -------------
>> >
>> > tstamp_mode: NONE
>> > period_step: 1
>> > avail_min: 1000
>> > start_threshold: 4000
>> > stop_threshold: 4000
>> > silence_threshold: 0
>> > silence_size: 0
>> > boundary: 2097152000
>> >
>> > status:
>> > --------
>> >
>> > state: RUNNING
>> > owner_pid   : 1852
>> > trigger_time: 3667.436640852
>> > tstamp      : 3756.680343977
>> > delay       : 3296
>> > avail       : 720
>> > avail_max   : 1000
>> > -----
>> > hw_ptr      : 712720
>> > appl_ptr    : 716000
>> > _______________________________________________
>> > Alsa-devel mailing list
>> > Alsa-devel at alsa-project.org
>> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>