On Fri, Nov 6, 2015 at 9:27 AM, Dinesh Ravindran <rite2dinesh@xxxxxxxxx> 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@xxxxxxxxx> wrote: >> >> On Fri, Nov 6, 2015 at 1:59 AM, Dinesh Ravindran <rite2dinesh@xxxxxxxxx> >> 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@xxxxxxxxxxxxxxxx >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
