Bug 80770

any reason not using line playback volume of your onboard sound card or analog input monitor of your oxygen mixer instead of the software loopback which have high latency  at least one capture period and one plpayback period ?

(In reply to comment #1)
> any reason not using line playback volume of your onboard sound card or
> analog input monitor of your oxygen mixer instead of the software loopback
> which have high latency  at least one capture period and one plpayback
> period ?

Yes, there's a reason that I'm using PulseAudio's loopback module instead of the ALSA monitor, directly. That doesn't have anything to do with this bug, though.

Since I last commented, I was able to reduce the 'Sink Latency' (and the module-loopback 'buffer latency') dramatically by correcting my PulseAudio default fragment size from the default 25 down to a more suitable 3.

Although the 'Buffer Latency' value is no longer ~200ms, which defeats my theory that module-loopback always uses the recorded default value of 200ms, the latencies are still exactly the same regardless of whether I supply latency_msec=1 or latency_msec=2000. I'm not sure of exactly how module-loopback settles on its latency, but it still appears that the latency_msec option is ignored, as far as I can tell.

you have to provide pulseaudio verbose log 

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/alsa-mixer.c?id=527078523815587bfd021bc1d10782403e9b3e84

module-loopback doesn't ignore the option, there's a different explanation for the observations. If changing the default fragment size has some effect, then it means that the sink (and probably source too if they're the same card) are not using timer-based scheduling, and hence don't support dynamic latency. Without dynamic latency, module-loopback can't control the overall latency. Or more specifically, it can't make the latency smaller than what the sink and source allow; it can be considered a bug that latency_msec=2000 doesn't make the latency higher, because that should be possible to do.

(In reply to comment #4)
> module-loopback doesn't ignore the option, there's a different explanation
> for the observations. If changing the default fragment size has some effect,
> then it means that the sink (and probably source too if they're the same
> card) are not using timer-based scheduling, and hence don't support dynamic
> latency. Without dynamic latency, module-loopback can't control the overall
> latency. Or more specifically, it can't make the latency smaller than what
> the sink and source allow; it can be considered a bug that latency_msec=2000
> doesn't make the latency higher, because that should be possible to do.

Thank you for the insight. It does seem like module-loopback isn't conrolling the overall latency, as you say, since its latency seems tied to the latency of my sink (and source, since they are indeed on the same card). That being said, I'm able to get less latency using pacat (record at 1ms, playback at 1ms. I don't know if the actual latency is as low as that request, but it's quite a bit faster than module-loopback, anyway). I'm not an engineer, but it seems like module-loopback would be doing something similar to what I'm doing with pacat (recording from an input and playing that back to an output in real time, unless it uses some kind of lower-level, less-intensive means), and, although it would arguably be difficult on many systems to have that running in the background at all times, I don't see why it wouldn't be possible by user request if it's possible for pacat.

If it should be possible to add ~more~ latency, anyway, then I'm not going to change the title of this bug, since changing the value of latency_msec has no effect one way or the other. Also, as far as I've read, the manual doesn't give any warning about soundcards that don't support dynamic latency; I think that I rightfully expected that changing the option value would do something, but it's ineffectual and no message is produced, so it's effectively being ignored.

Also, I can set arbitrarily high latencies using pacat, and they're accurately reproduced. For the record, and in case this helps anyone else, here's the pacat command that I'm using:

pacat -r --latency-msec=1 -d alsa_input.pci-0000_08_04.0.analog-stereo | pacat -p --latency-msec=1 -d alsa_output.pci-0000_08_04.0.analog-stereo

where "alsa_input.pci-0000_08_04.0.analog-stereo" and "alsa_output.pci-0000_08_04.0.analog-stereo" are my input and output devices, respectfully; anyone else's will be different.

Does anyone know of a command or option that I can use to make module-loopback produce valuable messages? It'd be interesting to see what it has to say for itself when it's ignoring or failing to implement my latency requests.

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/oxygen/oxygen_pcm.c?id=93943beb29be7084afb61556e96bc454079bfb0e

only a few sound cards support disable period wakeup

seem have lower period bytes minimum 64 than hda-Intel 128


err = snd_pcm_hw_constraint_step(runtime, 0,
					 SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 32);
	if (err < 0)
		return err;
	err = snd_pcm_hw_constraint_step(runtime, 0,
					 SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 32);


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_intel.c?id=2ae66c26550cd94b0e2606a9275eb0ab7070ad0e

does intel hda really support arbitrary period sizes since Fifo size is fixed

Can you attach a verbose log for a run where you just load module-loopback with latency_msec=1, so that we can figure out if the sink is really not using timer-based scheduling? Here are instructions: https://wiki.ubuntu.com/PulseAudio/Log

Looping back the audio with pacat shouldn't have any lower latency, unless the sink is slow to start so some audio gets received from the source before the sink starts to consume it (module-loopback doesn't handle that case well, a known issue).

what is the meaning of 1ms latency for 44100Hz as it contain 44.1 samples ?

The meaning of "1 ms" in this case is "as low as the sink can go". It probably can't provide that low latency.

(   0.138|   0.000) I: [pulseaudio] alsa-source.c: Using 4.0 fragments of size 2398 bytes (24.98ms), buffer size is 9594 bytes (99.94ms)
(   0.138|   0.000) D: [pulseaudio] alsa-source.c: hwbuf_unused=0
(   0.138|   0.000) D: [pulseaudio] alsa-source.c: setting avail_min=1
(   0.138|   0.000) D: [pulseaudio] alsa-util.c: snd_pcm_dump():
(   0.138|   0.000) D: [pulseaudio] alsa-util.c: Plug PCM: Hardware PCM card 2 'USB Device 0x46d:0x805' device 0 subdevice 0
(   0.138|   0.000) D: [pulseaudio] alsa-util.c: Its setup is:
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   stream       : CAPTURE
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   access       : MMAP_INTERLEAVED
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   format       : S16_LE
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   subformat    : STD
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   channels     : 1
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   rate         : 48000
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   exact rate   : 48000 (48000/1)
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   msbits       : 16
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   buffer_size  : 4797
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   period_size  : 1199
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   period_time  : 24979
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   tstamp_mode  : ENABLE
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   period_step  : 1
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   avail_min    : 1199
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   period_event : 1
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   start_threshold  : -1
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   stop_threshold   : 5400941853124067328
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   silence_threshold: 0
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   silence_size : 0
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   boundary     : 5400941853124067328
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   appl_ptr     : 0
(   0.138|   0.000) D: [pulseaudio] alsa-util.c:   hw_ptr       : 0


it strange that USB audio update in 1 ms interval for 48000Hz but pulseaudio  still  cannot set 25ms period time

Created attachment 102503 [details]
Verbose log of loading and unloading module-loopback w/ different latencies

(In reply to comment #7)
> Can you attach a verbose log for a run where you just load module-loopback
> with latency_msec=1, so that we can figure out if the sink is really not
> using timer-based scheduling? Here are instructions:
> https://wiki.ubuntu.com/PulseAudio/Log
> 
> Looping back the audio with pacat shouldn't have any lower latency, unless
> the sink is slow to start so some audio gets received from the source before
> the sink starts to consume it (module-loopback doesn't handle that case
> well, a known issue).

Thank you for your response. I've generated the preceding log using the instructions provided at your link. I loaded module-loopback with latency_msec=1, first, and then I unloaded it and re-loaded it with latency_msec=1000, both of which sound like the same latency, to me.

When I pacat my input to my output, both pacat's running with a specified 1ms latency, the latency is much less than when using module-loopback, perhaps for the reason that you provided. On the other hand, when I run the pacat's with 1000 msec or more of latency, I can actually delay the sound by seconds at a time, which is what I would expect. This doesn't appear to be possible with module-loopback; specifying large latencies up to 2000ms (the maximum supported latency, according to the manual) appears to have no effect on the latency, which stays the same as latency_msec=1.

.735|   0.000) I: [pulseaudio] source.c:     device.vendor.name = "C-Media Electronics Inc"
(   0.735|   0.000) I: [pulseaudio] source.c:     device.product.id = "8788"
(   0.735|   0.000) I: [pulseaudio] source.c:     device.product.name = "CMI8788 [Oxygen HD Audio] (Virtuoso 100 (Xonar DX))"
(   0.735|   0.000) I: [pulseaudio] source.c:     device.string = "2"
(   0.735|   0.000) I: [pulseaudio] source.c:     module-udev-detect.discovered = "1"
(   0.735|   0.000) I: [pulseaudio] source.c:     device.icon_name = "audio-card-pci"
(   0.735|   0.000) I: [pulseaudio] alsa-sink.c: Using 3.9 fragments of size 544 bytes (3.08ms), buffer size is 2112 bytes (11.97ms)

do the driver really support 3.9 fragments ?

|   0.000) D: [pulseaudio] alsa-mixer.c: Probe of element 'Hardware Master' succeeded (volume=0, switch=0, enumeration=0).
(   0.715|   0.000) W: [pulseaudio] alsa-mixer.c: Volume element Master has 8 channels. That's too much! I can't handle that!
(   0.715|   0.000) D: [pulseaudio] alsa-mixer.c: Probe of element 'Master' failed.

pulseaudio does not support 8 channels playback volume control


what hardware requiremen t are necessary for supporting dynamic latency ?


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/oxygen/oxygen_pcm.c?id=075140ea8bf1405057c072a84ccf4e0d3f2c76f5

disable period wake-up 

pointer callback is accurate 

arbitrary period size 



time scheduling seem disabled by pulseaudio found  usb audio device

seem missing this constraints

snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);

when common sample rate 44100 and 48000 Hz are multiple of three

latency time in ms may have rounding problems

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_intel.c?id=7bfe059e38b06a0d813d92b9b3e500455f6a2c99

nvidia controllers have 128 bytes alignment,

it strange that the period size is not multiple of 32


167|   0.000) D: [pulseaudio] alsa-util.c: Trying hdmi:4 with SND_PCM_NO_AUTO_FORMAT ...
(   0.167|   0.000) D: [pulseaudio] alsa-util.c: Managed to open hdmi:4
(   0.167|   0.000) D: [pulseaudio] alsa-util.c: Maximum hw buffer size is 7925 ms
(   0.200|   0.032) D: [pulseaudio] alsa-util.c: Set buffer size first (to 528 samples), period size second (to 132 samples).

0.849|   0.000) D: [pulseaudio] module-loopback.c: Loopback overall latency is 17.31 ms + 0.72 ms + 0.03 ms = 18.07 ms
(   0.849|   0.000) D: [pulseaudio] module-loopback.c: Should buffer 4224 bytes, buffered at minimum 128 bytes
(   0.849|   0.000) I: [pulseaudio] module-loopback.c: New rate of 43998 Hz not within 2鈥� of 44100 Hz, forcing smaller adjustment
(   0.849|   0.000) D: [pulseaudio] module-loopback.c: [alsa_output.pci-0000_08_04.0.analog-stereo] Updated sampling rate to 44011 Hz.

what  do 0.03ms mean ? 

there is rounding bug if it mean one sample time

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/oxygen/oxygen_pcm.c?id=d55d7a1cbbd069f8368ec5c67480d319e7b227b9

in theory pcie those oxygen cards should use 128 as  period byte min and only those pci oxygen cards can use 64 as period byte min

I believe this is fixed now in git?

(In reply to Alexander E. Patrakov from comment #19)
> I believe this is fixed now in git?

I don't think so. msec_latency=2000 still results in much too low latency.

This should be now fixed:
https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=f8e7354fac08e540ea1843dfba0155185e43e736