Please disregard this question. I changed the chunk size from 0x80 to 0x100 and resolved the issue. Playback h/w wants to be fed a larger chunk size, or it tends to get starved.

Best Regards, Paul Stone

On Mar 01, 2017, at 11:51 AM, Paul Stone metabagel@icloud.com wrote:

Correction: the discontinuity pattern seems to repeat itself every 3 buffers (24 ms).

There are 128 stereo frames per buffer.

-Paul Stone

On Mar 01, 2017, at 10:57 AM, Paul Stone metabagel@icloud.com wrote:

Hi all,

Summary: playback discontinuities that occur when PCM is configured for 16 kHz go away when it's configured at 8 kHz, even though the output still runs at 16 kHz.

I have written an ALSA driver for an embedded system. If I feed a synthetic sine wave to my output, it looks fine. However, when I use the following test, I see (with an oscilloscope) discontinuity in the sine wave on a buffer boundary (every 8 ms). Additionally, the pattern of the discontinuity repeats every 4 buffers (32 ms).

Here is the test I am running:

# gst-launch audiotestsrc ! 'audio/x-raw-int, channels=2, rate=16000, depth=16' ! alsasink device=plughw:3,0

The audio components of the system are a bit old:

gst-launch-0.10 version 0.10.36   GStreamer 0.10.36   alsa-lib-1.0.27.2-r1.cortexa9hf_vfp_neon

I have not added any configuration for this device in /etc/asound.conf.

Audio buffers are interleaved 16-bit stereo, output to FPGA which is configured with sampling frequency of 16 kHz. Buffer size is 128 frames.

* hardware definition */ static struct snd_pcm_hardware snd_imx_audio_playback_hw = {    .info = (SNDRV_PCM_INFO_MMAP |    SNDRV_PCM_INFO_INTERLEAVED |    SNDRV_PCM_INFO_BLOCK_TRANSFER    ),    .formats = SNDRV_PCM_FMTBIT_S16_LE, // Signed 16 bits    .rates = SNDRV_PCM_RATE_16000,    .rate_min = 16000,    .rate_max = 16000,    .channels_min = 2, // stereo    .channels_max = 2,    .buffer_bytes_max = MAX_BUFFER, // 10 buffers * BUFFER_SIZE    .period_bytes_min = BUFFER_SIZE, // 128 frames per buffer * 2 stereo samples per frame * 2 bytes per sample (16-bit)    .period_bytes_max = MAX_BUFFER,    // 10 buffers * BUFFER_SIZE    .periods_min = 1,    .periods_max = BUFFERS_PER_PAIR,    // 10 };

If I modify the test script to 8 kHz as follows:

# gst-launch audiotestsrc ! 'audio/x-raw-int, channels=2, rate=8000, depth=16' ! alsasink device=plughw:3,0

and modify the PCM h/w definition to 8 kHz as follows:

* hardware definition */ static struct snd_pcm_hardware snd_imx_audio_playback_hw = { .    .rates = SNDRV_PCM_RATE_8000,    .rate_min = 8000,    .rate_max = 8000, . };

... then the discontinuities go away. I get a pretty good sine wave output. Additionally, the output runs at 16 kHz, so it appears that even though ALSA has been told that the PCM runs at 8 kHz, it is keeping up with the true output rate of 16 kHz.

I don't believe the problem is in the FPGA, because the output looks fine if I synthesize a sine wave inside the driver. I am trying to investigate buffer usage, but any suggestions on how to approach this would be most welcome. I'm guessing that maybe ALSA is overflowing on every buffer boundary (dropped audio data), but I don't see any warning messages to that effect, and if that's the case I don't know why that would be happening or how to address it.

Best Regards, Paul Stone -Paul Stone