latency.c randomly gives persistent scratchy audio

[GitHub issues - opened]

alsa-project/alsa-lib issue #53 was opened from archenemies:

I had been intending to modify the example program test/latency.c in the alsa-lib distribution to build a filter.

However, I found the original program itself was unable to produce a good transfer of audio.

I am using it like

    ./latency -C plughw:3 -P hw:0,7 -r 44100 -m 256 -M 512 -c 2 -s 3000

but I also tried higher numbers (2048 and 4096) for -m and -M and this didn't help.

This command should theoretically work to transfer audio samples between the capture device, hw:3 which is a USB audio card with 3.5mm input, and the playback device hw:0,7 which is an HDMI monitor with builtin speakers. The second device has no volume control in alsamixer.

Most of the times when I run the above command, there is a scratchy sound which can be heard here

    mpv http://ix.io/2mPY

In the recording, whenever the music stops and starts again, it's because I killed the 'latency' program and restarted it. You can hear that there are different levels of distortion from one invocation to the next. The signal is coming from a digital audio player which is plugged into the USB sound card via analog 3.5mm. Nothing else changes about the setup, I am just stopping and starting "./latency".

The same level of scratchiness usually persists throughout the running of the program, however, each time the program is restarted a new level of scratchiness is chosen seemingly at random. It's almost like every time the program is started, a threshold is chosen uniformly at random, such that whenever the audio signal exceeds this threshold then it gets clipped. The other circumstances would seem to rule out buffer underflow or crystal drift, and there is no warning of dropped samples. I made some experiments, and even the effect of dropping every 10th sample sounds less distorted than this. But if it is from crystal drift, it should be more like every 1/1000th sample getting dropped. The sound that I am hearing is more like the result of zeroing or thresholding all the samples which exceed a certain amplitude, and a significant number of samples must be affected to make it sound this bad.

I do not notice this problem with "ecasound -i .. -o .." or with Pulseaudio's "module-loopback", which are both able to produce clear audio. As I uderstand it, ecasound does not do resampling to account for crystal drift. Pulseaudio's module-loopback does do adaptive resampling.

I'm including the command that I use, and the output. I don't know what some of those words mean - tstamp_mode, start_threshold, silence_threshold, period_event. Anyway, please let me know if it is possible to make this program behave more like Pulseaudio or Ecasound. I'll be happy to assist with reproduction issues and so on.

    $ ./latency -P hw:0,7 -C plughw:3 -r 44100 -m 4096 -M 16384 -c 2 -s 3000
    !!!Scheduler set to Round Robin with priority 99 FAILED!!!
    Playback device is hw:0,7
    Capture device is plughw:3
    Parameters are 44100Hz, S16_LE, 2 channels, non-blocking mode
    Poll mode: no
    Loop limit is 132300000 frames, minimum latency = 4096, maximum latency = 16384
    Hardware PCM card 0 'HD-Audio Generic' device 7 subdevice 0
    Its setup is:
      stream       : PLAYBACK
      access       : RW_INTERLEAVED
      format       : S16_LE
      subformat    : STD
      channels     : 2
      rate         : 44100
      exact rate   : 44100 (44100/1)
      msbits       : 16
      buffer_size  : 4096
      period_size  : 2048
      period_time  : 46439
      tstamp_mode  : NONE
      tstamp_type  : MONOTONIC
      period_step  : 1
      avail_min    : 2048
      period_event : 0
      start_threshold  : 2147483647
      stop_threshold   : 4096
      silence_threshold: 0
      silence_size : 0
      boundary     : 4611686018427387904
      appl_ptr     : 0
      hw_ptr       : 0
    Plug PCM: Route conversion PCM (sformat=S16_LE)
      Transformation table:
        0 <- 0
        1 <- 0
    Its setup is:
      stream       : CAPTURE
      access       : RW_INTERLEAVED
      format       : S16_LE
      subformat    : STD
      channels     : 2
      rate         : 44100
      exact rate   : 44100 (44100/1)
      msbits       : 16
      buffer_size  : 4096
      period_size  : 2048
      period_time  : 46439
      tstamp_mode  : NONE
      tstamp_type  : MONOTONIC
      period_step  : 1
      avail_min    : 2048
      period_event : 0
      start_threshold  : 2147483647
      stop_threshold   : 4096
      silence_threshold: 0
      silence_size : 0
      boundary     : 4611686018427387904
    Slave: Hardware PCM card 3 'USB Audio Device' device 0 subdevice 0
    Its setup is:
      stream       : CAPTURE
      access       : MMAP_INTERLEAVED
      format       : S16_LE
      subformat    : STD
      channels     : 1
      rate         : 44100
      exact rate   : 44100 (44100/1)
      msbits       : 16
      buffer_size  : 4096
      period_size  : 2048
      period_time  : 46439
      tstamp_mode  : NONE
      tstamp_type  : MONOTONIC
      period_step  : 1
      avail_min    : 2048
      period_event : 0
      start_threshold  : 2147483647
      stop_threshold   : 4096
      silence_threshold: 0
      silence_size : 0
      boundary     : 4611686018427387904
      appl_ptr     : 0
      hw_ptr       : 0
    Trying latency 4096 frames, 92879.819us, 92.879819ms (10.7666Hz)

The Linux distribution is Arch, the kernel is 5.6.10-arch1-1, x86_64 GNU/Linux. Thank you.

Issue URL     : https://github.com/alsa-project/alsa-lib/issues/53
Repository URL: https://github.com/alsa-project/alsa-lib