[alsa-devel] Audio quality issue - regular clicks are observed
Hi While testing the audio driver using aplay in blocking mode, a periodic murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun etc. Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable gaps aur hisses but the clicks are audible.
I have tried various combinations of period size and buffer size but the quality doesn't seem to improve. I checked the latency between to consecutive calls of snd_pcm_write in aplay and log is as follows.
I am having 16 periods of 1K size and from log it is seen that the latency is too much at the buffer boundary, i.e. higlighted and starred line in the logs. I think the clicks are caused due these huge delays since the clicks are also quite periodic. Any thoughts?
#aplay -Dhw:0,0 --rate=44100 --format=S16 --channels=2 --period-size=1024 --buffer-size=16384 Learning.wav
1 2 Latency = 0.000000 3 Latency = 0.001805 4 Latency = 0.000741 5 Latency = 0.000674 6 Latency = 0.000643 7 Latency = 0.000668 8 Latency = 0.000625 9 Latency = 0.000611 10 Latency = 0.000647 11 Latency = 0.000627 12 Latency = 0.000626 13 Latency = 0.000635 14 Latency = 0.000631 15 Latency = 0.000616 16 Latency = 0.000645 17 Latency = 0.000634 18 Latency = 0.000958 19 Avg Latency is => 0.000737 20 21 Latency = 0.371909 /********Too much latency***********/ 22 Latency = 0.000767 23 Latency = 0.000701 24 Latency = 0.000696 25 Latency = 0.000657 26 Latency = 0.000677 27 Latency = 0.000667 28 Latency = 0.000673 29 Latency = 0.000674 30 Latency = 0.000627 31 Latency = 0.000675 32 Latency = 0.000880 33 Latency = 0.000726 34 Latency = 0.000682 35 Latency = 0.000705 Latency = 0.000648 37 Avg Latency is => 0.023898 38 39 Latency = 0.361167 /********Too much latency***********/ 40 Latency = 0.000744 41 Latency = 0.000692 42 Latency = 0.000678 43 Latency = 0.000672 44 Latency = 0.000637 45 Latency = 0.000696 46 Latency = 0.000668 47 Latency = 0.000674 48 Latency = 0.000885 49 Latency = 0.000710 50 Latency = 0.000670 51 Latency = 0.000663 52 Latency = 0.000654 53 Latency = 0.000667 54 Latency = 0.000676 55 Avg Latency is => 0.023222 56 57 Latency = 0.361260 /********Too much latency***********/ 58 Latency = 0.000710 59 Latency = 0.000703 60 Latency = 0.000685 61 Latency = 0.000671 62 Latency = 0.000665 63 Latency = 0.000796 64 Latency = 0.000714 65 Latency = 0.000692 66 Latency = 0.000704 67 Latency = 0.000695
-Pharaoh
On Wed, 2007-08-22 at 22:13 +0530, Pharaoh . wrote:
Hi While testing the audio driver using aplay in blocking mode, a periodic murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun etc. Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable gaps aur hisses but the clicks are audible.
Clock domain mismatch issues cause periodic ticks that increase in frequency with increasing sample rate. It's possible your clocking the codec and controller in two different clock domains. i.e. I2S controller (bitclk and frame) clocked from CPU and codec clocked from separate crystal.
It's best to make sure that only one clock is clocking both the codec and digital audio interface.
Liam
On 8/23/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
On Wed, 2007-08-22 at 22:13 +0530, Pharaoh . wrote:
Hi While testing the audio driver using aplay in blocking mode, a periodic murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun etc.
Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable gaps
aur
hisses but the clicks are audible.
Clock domain mismatch issues cause periodic ticks that increase in frequency with increasing sample rate. It's possible your clocking the codec and controller in two different clock domains. i.e. I2S controller (bitclk and frame) clocked from CPU and codec clocked from separate crystal.
It's best to make sure that only one clock is clocking both the codec and digital audio interface.
Liam
I tried playing /dev/zero at the same sampling rate as a wav file, but /dev/zero played without any clicks i.e absolutely no sound heard, but while playing a wav file using same parameters clicks occur. I am thinking it is not about clocks mis-match, since I have checked it several times. I was thinking whether junk data is being processed at end of buffer size, but since /dev/zero plays well, I am ruling out that possibility also.
What else could explain the latencies at buffer ending as shown in the log in previous mail.
-Pharaoh.
On 8/23/07, Pharaoh . pharaoh137@gmail.com wrote:
On 8/23/07, Liam Girdwood <lg@opensource.wolfsonmicro.com > wrote:
On Wed, 2007-08-22 at 22:13 +0530, Pharaoh . wrote:
Hi While testing the audio driver using aplay in blocking mode, a
periodic
murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun
etc.
Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable
gaps aur
hisses but the clicks are audible.
Clock domain mismatch issues cause periodic ticks that increase in frequency with increasing sample rate. It's possible your clocking the codec and controller in two different clock domains. i.e. I2S controller (bitclk and frame) clocked from CPU and codec clocked from separate crystal.
It's best to make sure that only one clock is clocking both the codec and digital audio interface.
Liam
I tried playing /dev/zero at the same sampling rate as a wav file, but /dev/zero played without any clicks i.e absolutely no sound heard, but while playing a wav file using same parameters clicks occur. I am thinking it is not about clocks mis-match, since I have checked it several times. I was thinking whether junk data is being processed at end of buffer size, but since /dev/zero plays well, I am ruling out that possibility also.
What else could explain the latencies at buffer ending as shown in the log in previous mail.
-Pharaoh.
Further debug reveals that the pointer callback is called multiple times at the beginning of buffer . Could it be cause of latency? I am playing the same .wav file with using aplay with 16K buffer size and 4K period size .
Here is the log, audio_get_dma_pos is my pointer function. In period 0 it is called 4 times, while in period 1,2 and 3 it is called only once. Does it mean that first time pointer is called it is not getting correct value and it keeps retrying till it gets some sensible value?
[ 1013.037107] current period = 0 current offset = c000 [ 1013.044950] audio_get_dma_pos [ 1013.051770] audio_get_dma_pos [ 1013.056944] audio_get_dma_pos [ 1013.063780] audio_get_dma_pos [ 1013.135178] audio_get_dma_pos [ 1013.138445] current period = 1 current offset = 0 [ 1013.236261] audio_get_dma_pos [ 1013.239453] current period = 2 current offset = 4000 [ 1013.337485] audio_get_dma_pos [ 1013.340640] current period = 3 current offset = 8000 [ 1013.438684] audio_get_dma_pos [ 1013.441886] current period = 0 current offset = c000 [ 1013.449263] audio_get_dma_pos [ 1013.454452] audio_get_dma_pos [ 1013.461301] audio_get_dma_pos [ 1013.466879] audio_get_dma_pos [ 1013.539984] audio_get_dma_pos [ 1013.543208] current period = 1 current offset = 0 [ 1013.641070] audio_get_dma_pos [ 1013.644283] current period = 2 current offset = 4000 [ 1013.742383] audio_get_dma_pos [ 1013.745553] current period = 3 current offset = 8000 [ 1013.843631] audio_get_dma_pos [ 1013.846833] current period = 0 current offset = c000 [ 1013.854221] audio_get_dma_pos [ 1013.861027] audio_get_dma_pos [ 1013.866227] audio_get_dma_pos [ 1013.873090] audio_get_dma_pos [ 1013.944925] audio_get_dma_pos [ 1013.948187] current period = 1 current offset = 0 [ 1014.045988] audio_get_dma_pos [ 1014.049177] current period = 2 current offset = 4000 [ 1014.147209] audio_get_dma_pos [ 1014.150370] current period = 3 current offset = 8000
-pharaoh.
On 8/23/07, Pharaoh . pharaoh137@gmail.com wrote:
On 8/23/07, Pharaoh . pharaoh137@gmail.com wrote:
On 8/23/07, Liam Girdwood < lg@opensource.wolfsonmicro.com > wrote:
On Wed, 2007-08-22 at 22:13 +0530, Pharaoh . wrote:
Hi While testing the audio driver using aplay in blocking mode, a
periodic
murmur is observed, this increases with the audio volume and occurs even when there are no issues like xrun
etc.
Aplay was used in normal read/write mode i.e. no mmap. The song can be heard properly i.e. with no noticable
gaps aur
hisses but the clicks are audible.
Clock domain mismatch issues cause periodic ticks that increase in frequency with increasing sample rate. It's possible your clocking the codec and controller in two different clock domains. i.e. I2S controller (bitclk and frame) clocked from CPU and codec clocked from separate crystal.
It's best to make sure that only one clock is clocking both the codec and digital audio interface.
Liam
I tried playing /dev/zero at the same sampling rate as a wav file, but /dev/zero played without any clicks i.e absolutely no sound heard, but while playing a wav file using same parameters clicks occur. I am thinking it is not about clocks mis-match, since I have checked it several times. I was thinking whether junk data is being processed at end of buffer size, but since /dev/zero plays well, I am ruling out that possibility also.
What else could explain the latencies at buffer ending as shown in the log in previous mail.
-Pharaoh.
Further debug reveals that the pointer callback is called multiple times at the beginning of buffer . Could it be cause of latency? I am playing the same .wav file with using aplay with 16K buffer size and 4K period size .
Here is the log, audio_get_dma_pos is my pointer function. In period 0 it is called 4 times, while in period 1,2 and 3 it is called only once. Does it mean that first time pointer is called it is not getting correct value and it keeps retrying till it gets some sensible value?
[ 1013.037107] current period = 0 current offset = c000 [ 1013.044950] audio_get_dma_pos [ 1013.051770] audio_get_dma_pos [ 1013.056944] audio_get_dma_pos [ 1013.063780] audio_get_dma_pos [ 1013.135178 ] audio_get_dma_pos [ 1013.138445] current period = 1 current offset = 0 [ 1013.236261] audio_get_dma_pos [ 1013.239453] current period = 2 current offset = 4000 [ 1013.337485] audio_get_dma_pos [ 1013.340640 ] current period = 3 current offset = 8000 [ 1013.438684] audio_get_dma_pos [ 1013.441886] current period = 0 current offset = c000 [ 1013.449263] audio_get_dma_pos [ 1013.454452] audio_get_dma_pos [ 1013.461301 ] audio_get_dma_pos [ 1013.466879] audio_get_dma_pos [ 1013.539984] audio_get_dma_pos [ 1013.543208] current period = 1 current offset = 0 [ 1013.641070] audio_get_dma_pos [ 1013.644283] current period = 2 current offset = 4000 [ 1013.742383] audio_get_dma_pos [ 1013.745553] current period = 3 current offset = 8000 [ 1013.843631] audio_get_dma_pos [ 1013.846833] current period = 0 current offset = c000 [ 1013.854221] audio_get_dma_pos [ 1013.861027] audio_get_dma_pos [ 1013.866227] audio_get_dma_pos [ 1013.873090] audio_get_dma_pos [ 1013.944925] audio_get_dma_pos [ 1013.948187] current period = 1 current offset = 0 [ 1014.045988 ] audio_get_dma_pos [ 1014.049177] current period = 2 current offset = 4000 [ 1014.147209] audio_get_dma_pos [ 1014.150370] current period = 3 current offset = 8000
-pharaoh.
xrun debug revealed following
ALSA sound/core/pcm_lib.c:209: Unexpected hw_pointer value [1] (stream = 0, delta: -1024, max jitter = 8192): wrong interrupt acknowledge?
This means that my pointer function is not working correctly.
participants (2)
-
Liam Girdwood -
Pharaoh .