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
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