[alsa-devel] Alsa Crackling Noise

Dinesh Ravindran rite2dinesh at gmail.com
Fri Nov 6 18:27:45 CET 2015


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.




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
>


More information about the Alsa-devel mailing list